未解决。在研究中
解决:
数据类型的问题:
表8-4. 字符类型
名字
描述
character varying(n),varchar(n)
变长,有长度限制
character(n),char(n)
定长,不足补空白
text
变长,无长度限制
sql 定义了两种基本的字符类型:character varying(n) 和 character(n) ,这里的n 是一个正整数。两种类型都可以存储最多n 个字符的字符串。试图存储更长的字符串到这些类型的字段里会产生一个错误,除非超出长度的字符都是空白,这种情况下该字符串将被截断为最大长度。这个看上去有点怪异的例外是 sql 标准要求的。如果要存储的字符串比声明的长度短,类型为character 的数值将会用空白填满;而类型为character varying 的数值将只是存储短些的字符串。
如果我们明确地把一个数值转换成 character varying(n) 或 character(n) ,那么超长的数值将被截断成n 个字符,且不会抛出错误。这也是 sql 标准的要求。
varchar(n) 和 char(n) 分别是 character varying(n) 和character(n)的别名,没有声明长度的character 等于 character(1) ;如果不带长度说明词使用character varying,那么该类型接受任何长度的字符串。后者是 Postgresql 的扩展。
另外,Postgresql 提供 text 类型,它可以存储任何长度的字符串。尽管类型 text 不是 sql 标准,但是许多其它 sql 数据库系统也有它。
character 类型的数值物理上都用空白填充到指定的长度 n 并且以这种方式存储和显示。不过,填充的空白在是无语意的。在比较两个character 值的时候,填充的空白都不会被关注,在转换成其它字符串类型的时候,character 值里面的空白会被删除。请注意,在character varying 和text 数值里,结尾的空白是有语意的。
这些类型的存储需求是 4 字节加上实际的字符串,如果是 character 的话再加上填充的字节。长的字符串将会自动被系统压缩,因此在磁盘上的物理需求可能会更少些。长的数值也会存储在后台表里面,这样它们就不会干扰对短字段值的快速访问。不管怎样,允许存储的最长字符串大概是 1GB 。允许在数据类型声明中出现的n 的最大值比这还小。修改这个行为没有什么意义,因为在多字节编码下字符和字节的数目可能差别很大。如果你想存储没有特定上限的长字符串,那么使用text 或没有长度声明词的 character varying ,而不要选择一个任意长度限制。
【提示】这三种类型之间没有性能差别,只不过是在使用 character 的时候增加了存储尺寸。虽然在某些其它的数据库系统里,character(n) 有一定的性能优势,但在 Postgresql 里没有。在大多数情况下,应该使用text 或character varying
顺便收藏下:
bigint | int8 | 有符号8字节整数 |
bigserial | serial8 | 自增8字节整数 |
bit [ (n ) ] | 定长位串 | |
bit varying [ (n ) ] | varbit | 变长位串 |
boolean | bool | 逻辑布尔值(true/false) |
Box | 平面中的矩形 | |
bytea | 二进制数据("字节数组" ) | |
character varying [ (n ) ] | varchar [ (n ) ] | 变长字符串 |
character [ (n ) ] | char [ (n ) ] | 定长字符串 |
cidr | IPv4 或 IPv6 网络地址 | |
circle | 平面中的圆 | |
date | 日历日期 (年,月,日) | |
double precision | float8 | 双精度浮点数(8 字节) |
inet | IPv4 或 IPv6 主机地址 | |
integer | int,int4 | 有符号4字节整数 |
interval [ fields ] [ (p) ] | 时间间隔 | |
line | 平面中的无限上直线 | |
lseg | 平面中的线段 | |
macaddr | MAC 地址 | |
money | 货币金额 | |
numeric [ (p , s ) ] | decimal [ (p , s ) ] | 可选精度的准确数字 |
path | 平面中的几何路径 | |
point | 平面中的点 | |
polygon | 平面中的闭合几何路径 | |
real | float4 | 单精度浮点数 (4 字节) |
smallint | int2 | 有符号两字节整数 |
serial | serial4 | 自增4字节整形 |
text | 变长字符串 | |
time [ (p ) ] [ without time zone ] | 一天中的时间(不包括时区) | |
time [ (p ) ] with time zone | timetz | 一开中的时间,包括时区 |
timestamp [ (p ) ] [ without time zone ] | 日期和时间、时间戳 (不包括时区) | |
timestamp [ (p ) ] with time zone | timestamptz | 日期和时间、时间戳,包括时区 |
tsquery | 文本搜索查询 | |
tsvector | 文本搜索文档 | |
txid_snapshot | 用户级事务ID快照 | |
uuid | UUID | |
xml | XML数据 |
详细说明:
postgresql数据类型 -------转自他人
表8-2. 数值类型
名字
存储空间
描述
范围
smallint
2 字节
小范围整数
-32768 到 +32767
integer
4 字节
常用的整数
-2147483648 到 +2147483647
bigint
8 字节
大范围的整数
-9223372036854775808 到 9223372036854775807
decimal
变长
用户声明精度,精确
无限制
numeric
变长
用户声明精度,精确
无限制
real
4 字节
变精度,不精确
6 位十进制数字精度
double precision
8 字节
变精度,不精确
15 位十进制数字精度
serial
4 字节
自增整数
1 到 2147483647
bigserial
8 字节
大范围的自增整数
1 到 9223372036854775807
numeric 类型可以存储最多 1000 位精度的数字并且准确地进行计算。我们特别建议将它用于货币金额和其它要求精确计算的场合。不过,numeric 类型上的算术运算比整数类型或者我们下一节描述的浮点数类型要慢很多。
在随后的内容里,我们使用下述术语:一个 numeric 类型的标度(scale)是小数部分的位数,精度(precision)是全部数据位的数目,也就是小数点两边的位数总和。因此数字 23.5141 的精度为 6 而标度为 4 。你可以认为整数的标度为零。
numeric 字段的最大精度和最大标度都是可以配置的。要声明一个字段的类型为 numeric ,你可以用下面的语法:
NUMERIC(precision,scale)
精度必须为正数,标度可以为零或者正数。另外,
NUMERIC(precision)
选择了标度为 0 。不带任何精度与标度的声明
NUMERIC
则创建一个可以存储一个直到实现精度上限的任意精度和标度的数值,一个这样类型的字段将不会把输入数值转化成任何特定的标度,而带有标度声明的 numeric 字段将把输入值转化为该标度。sql 标准要求缺省的标度是 0(也就是转化成整数精度)。我们觉得这样做有点没用。如果你关心移植性,那你最好总是明确声明精度和标度。
如果一个要存储的数值的标度比字段声明的标度高,那么系统将尝试圆整(四舍五入)该数值到指定的小数位。然后,如果小数点左边的数据位数超过了声明的精度减去声明的标度,那么将抛出一个错误。
numeric 类型的数据值在物理上是不带任何前导或者后缀零的形式存储的。因此,字段上声明的精度和标度都是最大值,而不是固定分配的。在这个方面,numeric 类型更类似于 varchar(n) 而不是 char(n) 。实际存储是每四个十进制位两个字节,然后在整个数据上加上八个字节的额外开销。
除了普通的数字值之外,numeric 类型允许用特殊值 NaN 表示"不是一个数字"。任何在 NaN 上面的操作都生成另外一个 NaN 。如果在 sql 命令里把这些值当作一个常量写,你必须在其周围放上单引号,比如 UPDATE table SET x = 'NaN' 。在输入时,字符串 NaN 是大小写无关的。
类型 decimal 和 numeric 是等效的。两种类型都是 sql 标准。
表8-4. 字符类型
名字
描述
character varying(n),varchar(n)
变长,有长度限制
character(n),char(n)
定长,不足补空白
text
变长,无长度限制
sql 定义了两种基本的字符类型:character varying(n) 和 character(n) ,这里的 n 是一个正整数。两种类型都可以存储最多 n 个字符的字符串。试图存储更长的字符串到这些类型的字段里会产生一个错误,除非超出长度的字符都是空白,这种情况下该字符串将被截断为最大长度。这个看上去有点怪异的例外是 sql 标准要求的。如果要存储的字符串比声明的长度短,类型为 character 的数值将会用空白填满;而类型为 character varying 的数值将只是存储短些的字符串。
如果我们明确地把一个数值转换成 character varying(n) 或 character(n) ,那么超长的数值将被截断成 n 个字符,且不会抛出错误。这也是 sql 标准的要求。
varchar(n) 和 char(n) 分别是 character varying(n) 和 character(n)的别名,没有声明长度的 character 等于 character(1) ;如果不带长度说明词使用 character varying,那么该类型接受任何长度的字符串。后者是 Postgresql 的扩展。
另外,Postgresql 提供 text 类型,它可以存储任何长度的字符串。尽管类型 text 不是 sql 标准,但是许多其它 sql 数据库系统也有它。
character 类型的数值物理上都用空白填充到指定的长度 n 并且以这种方式存储和显示。不过,填充的空白在是无语意的。在比较两个 character 值的时候,填充的空白都不会被关注,在转换成其它字符串类型的时候,character 值里面的空白会被删除。请注意,在 character varying 和 text 数值里,结尾的空白是有语意的。
这些类型的存储需求是 4 字节加上实际的字符串,如果是 character 的话再加上填充的字节。长的字符串将会自动被系统压缩,因此在磁盘上的物理需求可能会更少些。长的数值也会存储在后台表里面,这样它们就不会干扰对短字段值的快速访问。不管怎样,允许存储的最长字符串大概是 1GB 。允许在数据类型声明中出现的 n 的最大值比这还小。修改这个行为没有什么意义,因为在多字节编码下字符和字节的数目可能差别很大。如果你想存储没有特定上限的长字符串,那么使用 text 或没有长度声明词的 character varying ,而不要选择一个任意长度限制。
【提示】这三种类型之间没有性能差别,只不过是在使用 character 的时候增加了存储尺寸。虽然在某些其它的数据库系统里,character(n) 有一定的性能优势,但在 Postgresql 里没有。在大多数情况下,应该使用 text 或 character varying 。
表8-9. 日期/时间类型
名字
存储空间
描述
最低值
最高值
分辨率
timestamp [ (p) ] [ without time zone ]
8 字节
日期和时间
4713 BC
5874897 AD
1 毫秒 / 14 位
timestamp [ (p) ] with time zone
8 字节
日期和时间,带时区
4713 BC
5874897 AD
1 毫秒 / 14 位
interval [ (p) ]
12 字节
时间间隔
-178000000 年
178000000 年
1 毫秒 / 14 位
date
4 字节
只用于日期
4713 BC
5874897 AD
1 天
time [ (p) ] [ without time zone ]
8 字节
只用于一日内时间
00:00:00
24:00:00
1 毫秒 / 14 位
time [ (p) ] with time zone
12 字节
只用于一日内时间,带时区
00:00:00+1459
24:00:00-1459
1 毫秒 / 14 位