合 PG数据类型简介
Tags: PGPostgreSQL数据类型bigserialbyteajsonjsonbserialsmallserialtext
- 数值类型
- 1. 整数类型
- 2. 任意精度数字
- 注意
- 注意
- 3. 浮点类型
- 注意
- 注意
- 注意
- 4. 序数类型(自增类型)
- 注意
- 注意
- 示例
- 货币类型
- 字符类型
- 提示
- 日期/时间类型
- 注意
- 1. 日期/时间输入
- 1.1. 日期
- 1.2. 时间
- 1.3. 时间戳
- 1.4. 特殊值
- 小心
- 2. 日期/时间输出
- 注意
- 3. 时区
- 4. 间隔输入
- 5. 间隔输出
- 布尔类型
- 枚举类型
- 1. 枚举类型的声明
- 2. 排序
- 3. 类型安全性
- 4. 实现细节
- 几何类型
- 1. 点
- 2. 线
- 3. 线段
- 4. 方框
- 5. 路径
- 6. 多边形
- 7. 圆
- 网络地址类型
- 1. inet
- 2. cidr
- 3. inet和cidr
- 提示
- 4. macaddr
- 5. macaddr8
- 位串类型
- 注意
- 文本搜索类型
- 1. tsvector
- 2. tsquery
- UUID 类型
- XML 类型
- 创建XML值
- 编码处理
- 小心
- 访问XML值
- JSON 类型
- 数组类型
- 声明数组
- 插入值
- 访问数组
- 修改数组
- 数组中检索
- 复合类型
- 声明复合类型
- 复合类型值输入
- 访问复合类型
- 范围类型
- 对象标识符类型
- 伪类型
- pg_lsn 类型
- 域类型
- 参考
PostgreSQL 数据类型
数据类型是我们在创建表的时候为每个字段设置的。
设置数据类型的好处:
PostgreSQL提 供了丰富的数据类型。用户可以使用 CREATE TYPE 命令在数据库中创建新的数据类型。PostgreSQL 的数据类型有很多种,下面我们具体来说明。
官方:http://postgres.cn/docs/13/datatype.html
http://postgres.cn/docs/13/extend-type-system.html
数值类型
数值类型由 2 字节、4 字节或 8 字节的整数以及 4 字节或 8 字节的浮点数和可选精度的十进制数组成。
下表列出了可用的数值类型。
名字 | 存储长度 | 描述 | 范围 |
---|---|---|---|
smallint | 2 字节 | 小范围整数 | -32768 到 +32767 |
integer | 4 字节 | 常用的整数 | -2147483648 到 +2147483647 |
bigint | 8 字节 | 大范围整数 | -9223372036854775808 到 +9223372036854775807 |
decimal | 可变长 | 用户指定的精度,精确 | 小数点前 131072 位;小数点后 16383 位 |
numeric | 可变长 | 用户指定的精度,精确 | 小数点前 131072 位;小数点后 16383 位 |
real | 4 字节 | 可变精度,不精确 | 6 位十进制数字精度 |
double precision | 8 字节 | 可变精度,不精确 | 15 位十进制数字精度 |
smallserial | 2 字节 | 自增的小范围整数 | 1 到 32767 |
serial | 4 字节 | 自增整数,序列类型,类似于MySQL中的auto_increment | 1 到 2147483647 |
bigserial | 8 字节 | 自增的大范围整数 | 1 到 9223372036854775807 |
1. 整数类型
类型smallint
、integer
和bigint
存储各种范围的全部是数字的数,也就是没有小数部分的数字。试图存储超出范围以外的值将导致一个错误。
常用的类型是integer
,因为它提供了在范围、存储空间和性能之间的最佳平衡。一般只有在磁盘空间紧张的时候才使用 smallint
类型。而只有在integer
的范围不够的时候才使用bigint
。
SQL只声明了整数类型integer
(或int
)、smallint
和bigint
。类型int2
、int4
和int8
都是扩展,也在许多其它SQL数据库系统中使用。
2. 任意精度数字
类型numeric
可以存储非常多位的数字。我们特别建议将它用于货币金额和其它要求计算准确的数量。numeric
值的计算在可能的情况下会得到准确的结果,例如加法、减法、乘法。不过,numeric
类型上的算术运算比整数类型或者下一节描述的浮点数类型要慢很多。
在随后的内容里,我们使用了下述术语:一个numeric
的precision(精度)是整个数中有效位的总数,也就是小数点两边的位数。numeric
的scale(刻度)是小数部分的数字位数,也就是小数点右边的部分。因此数字 23.5141 的精度为6而刻度为4。可以认为整数的刻度为零。
numeric
列的最大精度和最大比例都是可以配置的。要声明一个类型为numeric
的列,你可以用下面的语法:
1 | NUMERIC(precision, scale) |
精度必须为正数,比例可以为零或者正数。另外:
1 | NUMERIC(precision) |
选择比例为 0 。如果使用
1 | NUMERIC |
创建一个列时不使用精度或比例,则该列可以存储任何精度和比例的数字值,并且值的范围最多可以到实现精度的上限。一个这种列将不会把输入值转化成任何特定的比例,而带有比例声明的numeric
列将把输入值转化为该比例(SQL标准要求缺省的比例是 0,即转化成整数精度。我们觉得这样做有点没用。如果你关心移植性,那你最好总是显式声明精度和比例)。
注意
显式指定类型精度时的最大允许精度为 1000,没有指定精度的NUMERIC
受到表 8.2中描述的限制所控制。
如果一个要存储的值的比例比列声明的比例高,那么系统将尝试圆整(四舍五入)该值到指定的分数位数。 然后,如果小数点左边的位数超过了声明的精度减去声明的比例,那么抛出一个错误。
数字值在物理上是以不带任何前导或者后缀零的形式存储。 因此,列上声明的精度和比例都是最大值,而不是固定分配的 (在这个方面,numeric
类型更类似于varchar(n)
, 而不像char(n)
)。 实际存储要求是每四个十进制位组用两个字节,再加上三到八个字节的开销。
除了普通的数字值之外,numeric
类型允许特殊值NaN
, 表示“不是一个数字”。任何在 NaN
上面的操作都生成另外一个NaN
。 如果在 SQL 命令里把这些值当作一个常量写,你必须在其周围放上单引号,例如UPDATE table SET x = 'NaN'
。在输入时,字串NaN
被识别为大小写无关。
注意
在“不是一个数字”概念的大部分实现中,NaN
被认为不等于任何其他数字值(包括NaN
)。为了允许numeric
值可以被排序和使用基于树的索引,PostgreSQL把NaN
值视为相等,并且比所有非NaN
值都要大。
类型decimal
和numeric
是等效的。两种类型都是SQL标准的一部分。
在对值进行圆整时,numeric
类型会圆到远离零的整数,而(在大部分机器上)real
和double precision
类型会圆到最近的偶数上。例如:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | SELECT x, round(x::numeric) AS num_round, round(x::double precision) AS dbl_round FROM generate_series(-3.5, 3.5, 1) as x; x | num_round | dbl_round ------+-----------+----------- -3.5 | -4 | -4 -2.5 | -3 | -2 -1.5 | -2 | -2 -0.5 | -1 | -0 0.5 | 1 | 0 1.5 | 2 | 2 2.5 | 3 | 2 3.5 | 4 | 4 (8 rows) |
3. 浮点类型
数据类型real
和double precision
是不精确的、变精度的数字类型。 在所有当前支持的平台上,这些类型是IEEE标准 754 二进制浮点算术(分别对应单精度和双精度)的实现, 一直到下层处理器、操作系统和支持它的编译器。
不准确意味着一些值不能准确地转换成内部格式并且是以近似的形式存储的,因此存储和检索一个值可能出现一些缺失。 处理这些错误以及这些错误是如何在计算中传播的主题属于数学和计算机科学的一个完整的分支, 我们不会在这里进一步讨论它,这里的讨论仅限于如下几点:
- 如果你要求准确的存储和计算(例如计算货币金额),应使用
numeric
类型。 - 如果你想用这些类型做任何重要的复杂计算,尤其是那些你对范围情况(无穷、下溢)严重依赖的事情,那你应该仔细评诂你的实现。
- 用两个浮点数值进行等值比较不可能总是按照期望地进行。
在所有当前支持的平台上,real
类型的范围是 1E-37 to 1E+37 ,精度至少是 6 位小数。 double precision
类型的范围是 1E-307 to 1E+308 ,精度至少是 15 位数字。 太大或者太小的值都会导致错误。 如果输入数字的精度太高,那么可能发生四舍五入。 太接近零的数字,如果不能体现出与零的区别就会导致下溢错误。
默认情况下,浮点值以其最短精确的十进制表示的文本形式输出;所产生的十进制值与相同二进制精度的任何其他的值表示相比,更接近于真实存储的二进制值。 (但是,当前输出值永远不会精确地处于两个可表示的值之间,以免输入程序不能正确遵守舍近取整法则。) 对于float8
值,此值最多使用 17 个有效十进制数字,对于float4
值,最多使用9个数字。
注意
生成这种最短精确的输出格式比历史的四舍五入的格式要快得多。
为了与PostgreSQL的较旧版本生成的输出兼容,并允许降低输出精度,可以使用extra_float_digits参数选择四舍五入的十进制输出。 将值设置为0将恢复以前的默认值,即将值四舍五入为6(对于float4
)或15(对于float8
)个有效的十进制数字。 设置负值会进一步减少位数。 例如-2会将输出分别舍入到4或13位数字。
设置extra_float_digits位任何大于 0 的值将选择最短精确格式。
注意
需要更精确值的应用需要设置extra_float_digits为3以获取更精确值。 为了版本之间的最大兼容性,他们可以继续这样做。
除了普通的数字值之外,浮点类型还有几个特殊值:
Infinity
-Infinity
NaN
这些分别代表 IEEE 754 特殊值“infinity”、“negative infinity”以及“not-a-number”, 如果在 SQL 命令里把这些数值当作常量写,你必须在它们周围放上单引号,例如UPDATE table SET x = '-Infinity'
。 在输入时,这些字符串是以大小写不敏感的方式识别的。
注意
IEEE754指定NaN
不应该与任何其他浮点值(包括NaN
)相等。为了允许浮点值被排序或者在基于树的索引中使用,PostgreSQL将NaN
值视为相等,并且比所有非NaN
值要更大。
PostgreSQL还支持 SQL 标准表示法float
和float(*
p*)
用于声明非精确的数字类型。在这里,p
指定以二进制位表示的最低可接受精度。 在选取real
类型的时候,PostgreSQL接受float(1)
到float(24)
,在选取double precision
的时候,接受float(25)
到float(53)
。在允许范围之外的p
值将导致一个错误。没有指定精度的float
将被当作是double precision
。
4. 序数类型(自增类型)
注意
这一节描述了PostgreSQL特有的创建一个自增列的方法。另一种方法是使用SQL标准的标识列特性,它在CREATE TABLE中描述。
smallserial
、serial
和bigserial
类型不是真正的类型,它们只是为了创建唯一标识符列而存在的方便符号(类似其它一些数据库中支持的AUTO_INCREMENT
属性)。 在目前的实现中,下面一个语句:
1 2 3 | CREATE TABLE tablename ( colname SERIAL ); |
等价于以下语句:
1 2 3 4 5 | CREATE SEQUENCE tablename_colname_seq AS integer; CREATE TABLE tablename ( colname integer NOT NULL DEFAULT nextval('tablename_colname_seq') ); ALTER SEQUENCE tablename_colname_seq OWNED BY tablename.colname; |
因此,我们就创建了一个整数列并且把它的缺省值安排为从一个序列发生器取值。应用了一个NOT NULL
约束以确保空值不会被插入(在大多数情况下你可能还希望附加一个UNIQUE
或者PRIMARY KEY
约束避免意外地插入重复的值,但这个不是自动发生的)。最后,该序列被标记为“属于”该列,这样当列或表被删除时该序列也会被删除。
注意
因为smallserial
、serial
和bigserial
是用序列实现的,所以即使没有删除过行,在出现在列中的序列值可能有“空洞”或者间隙。如果一个从序列中分配的值被用在一行中,即使该行最终没有被成功地插入到表中,该值也被“用掉”了。例如,当插入事务回滚时就会发生这种情况。更多信息参见第 9.17 节中的nextval()
。
要使用serial
列插入序列的下一个数值到表中, 请指定serial
列应该被赋予其缺省值。我们可以通过在INSERT
语句中把该列排除在列列表之外来实现,也可以通过使用DEFAULT
关键字来实现。
类型名serial
和serial4
是等效的: 两个都创建integer
列。类型名bigserial
和serial8
也一样,只不过它们创建一个 bigint
列。如果你预计在表的生存期中使用的标识符数目超过 231 个,那么你应该使用bigserial
。类型名smallserial
和serial2
也以相同方式工作,只不过它们创建一个smallint
列。
为一个serial
列创建的序列在所属的列被删除的时候自动删除。你可以在不删除列的情况下删除序列,但是这会强制删除该列的默认值表达式。
示例
在 PostgreSQL 中,SERIAL 是一种特殊的数据类型,它用于创建一个自动递增的列,通常用于主键列。下面是一个使用 SERIAL 类型的示例:
首先,创建一个名为 "students" 的表,其中包含一个 "id" 列,这个列是 SERIAL 类型,用于自动递增:
1 2 3 4 5 | CREATE TABLE students ( id SERIAL PRIMARY KEY, name VARCHAR(50), age INT ); |
在这个示例中,我们使用了 SERIAL 类型来创建一个自动递增的主键列 "id"。通过指定 PRIMARY KEY 约束,我们将 "id" 列设置为表的主键。
现在,我们可以向 "students" 表中插入数据,并省略 "id" 列:
1 2 3 | INSERT INTO students (name, age) VALUES ('Alice', 20); INSERT INTO students (name, age) VALUES ('Bob', 22); INSERT INTO students (name, age) VALUES ('Charlie', 21); |
在这个示例中,我们没有指定 "id" 列的值,因为它会自动递增。每次插入一行数据时,"id" 列的值都会自动递增。
如果我们想手动设置 "id" 列的值,可以使用 SETVAL 函数:
1 | SELECT setval('students_id_seq', 100); |
这将把 "students" 表的 "id" 列的下一个值设置为 100。请注意,"students_id_seq" 是由 PostgreSQL 自动生成的序列名称。
货币类型
money 类型存储带有固定小数精度的货币金额。小数的精度由数据库的参数lc_monetary设置决定。表中展示的范围假设有两个小数位。可接受的输入格式很多,包括整数和浮点数文字,以及常用的货币格式,如'$1,000.00'
。 输出通常是最后一种形式,但和区域相关。
numeric、int 和 bigint 类型的值可以转换为 money,不建议使用浮点数来处理处理货币类型,因为存在舍入错误的可能性。
名字 | 存储容量 | 描述 | 范围 |
---|---|---|---|
money | 8 字节 | 货币金额 | -92233720368547758.08 到 +92233720368547758.07 |
由于这种数据类型的输出是区域敏感的,因此将money
数据装入到一个具有不同lc_monetary
设置的数据库是不起作用的。为了避免这种问题,在恢复一个转储到一个新数据库中之前,应确保新数据库的lc_monetary
设置和被转储数据库的相同或者具有等效值。
数据类型numeric
、int
和bigint
的值可以被造型成money
。从数据类型real
和double precision
的转换可以通过先造型成numeric
来实现,例如:
1 | SELECT '12.34'::float8::numeric::money; |
但是,我们不推荐这样做。浮点数不应该被用来处理货币,因为浮点数可能会有圆整错误。
一个money
值可以在不损失精度的情况下被造型成numeric
。转换到其他类型可能会丢失精度,并且必须采用两个阶段完成:
1 | SELECT '52093.89'::money::numeric::float8; |
一个money
值被一个整数值除的除法结果会被截去分数部分。要得到圆整的结果,可以除以一个浮点值,或者在除法之前把money
转换成numeric
然后在除法之后转回money
(如果要避免精度丢失的风险则后者更好)。当一个money
值被另一个money
值除时,结果是double precision
(即一个纯数字,而不是金额),在除法中货币单位被约掉了。
字符类型
- varchar = text
- char = char(1)
- varchar(n) 唯一好处是:当字符串超过n时会执行失败
- PostgreSQL中三种字符类型没有性能差异,推荐用text或varchar,要求限制长度则用varchar(n)
下表列出了 PostgreSQL 所支持的字符类型:
序号 | 名字 & 描述 |
---|---|
1 | character varying(n), varchar(n)变长,有长度限制 |
2 | character(n), char(n)f定长,不足补空白 |
3 | 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
类型值时不会考虑它们。在空白有意义的排序规则中,这种行为可能会 产生意料之外的结果,例如SELECT 'a '::CHAR(2) collate "C" < E'a\n'::CHAR(2)
会返回真(即便C
区域会认为一个空格比新行更大)。当把一个character
值转换成其他 字符串类型之一时,拖尾的空白会被移除。请注意,在character varying
和text
值里, 结尾的空白语意上是有含义的,并且在使用模式匹配(如LIKE
和正则表达式)时也会被考虑。
这些类型的存储需求是 4 字节加上实际的字串,如果是 character 的话再加上填充的字节。长的字串将会自动被系统压缩, 因此在磁盘上的物理需求可能会更少些。长的数值也会存储在后台表里面,这样它们就不会干扰对短字段值的快速访问。 不管怎样,允许存储的最长字串大概是 1 GB。 (允许在数据类型声明中出现的的 n 的最大值比这还小。 修改这个行为没有甚么意义,因为在多字节编码下字符和字节的数目可能差别很大。 如果你想存储没有特定上限的长字串,那么使用 text 或者没有长度声明词的 character varying, 而不要选择一个任意长度限制。) 一个短串(最长126字节)的存储要求是1个字节外加实际的串,该串在character
情况下包含填充的空白。长一些的串在前面需要4个字节而不是1个字节。长串会被系统自动压缩,这样在磁盘上的物理需求可能会更少。非常长的值也会被存储在背景表中,这样它们不会干扰对较短的列值的快速访问。在任何情况下,能被存储的最长的字符串是1GB(数据类型定义中n能允许的最大值比这个值要小。修改它没有用处,因为对于多字节字符编码来说,字符的数量和字节数可能完全不同。如果你想要存储没有指定上限的长串,使用text
或没有长度声明的character varying
,而不是给出一个任意长度限制)。
提示
这三种类型之间没有性能差别,只不过是在使用填充空白的类型的时候需要更多存储尺寸,以及在存储到一个有长度约束的列时需要少量额外CPU周期来检查长度。虽然在某些其它的数据库系统里,character(n)
有一定的性能优势,但在PostgreSQL里没有。事实上,character(n)
通常是这三种类型之中最慢的一个,因为它需要额外的存储开销。在大多数情况下,应该使用text
或者character varying
。
请参考第 4.1.2.1 节获取关于串文本的语法的信息,以及参阅第 9 章获取关于可用操作符和函数的信息。 数据库的字符集决定用于存储文本值的字符集;有关字符集支持的更多信息,请参考第 23.3 节。
例 8.1. 使用字符类型
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | CREATE TABLE test1 (a character(4)); INSERT INTO test1 VALUES ('ok'); SELECT a, char_length(a) FROM test1; -- (1) a | char_length ------+------------- ok | 2 CREATE TABLE test2 (b varchar(5)); INSERT INTO test2 VALUES ('ok'); INSERT INTO test2 VALUES ('good '); INSERT INTO test2 VALUES ('too long'); ERROR: value too long for type character varying(5) INSERT INTO test2 VALUES ('too long'::varchar(5)); -- explicit truncation SELECT b, char_length(b) FROM test2; b | char_length -------+------------- ok | 2 good | 5 too l | 5 |
在PostgreSQL里另外还有两种定长字符类型,在表 8.5里显示。 name
类型只用于在内部系统目录中存储标识符并且不是给一般用户使用的。该类型长度当前定为 64 字节(63 可用字符加结束符)但在C
源代码应该使用常量 NAMEDATALEN
引用。这个长度是在编译的时候设置的(因而可以为特殊用途调整),缺省的最大长度在以后的版本可能会改变。类型"char"
(注意引号)和 char(1)
是不一样的,它只用了一个字节的存储空间。它在系统内部用于系统目录当做简化的枚举类型用。
表 8.5. 特殊字符类型
名字 | 存储尺寸 | 描述 |
---|---|---|
"char" | 1字节 | 单字节内部类型 |
name | 64字节 | 用于对象名的内部类型 |
日期/时间类型
下表列出了 PostgreSQL 支持的日期和时间类型。
名字 | 存储空间 | 描述 | 最低值 | 最高值 | 分辨率 |
---|---|---|---|---|---|
timestamp [ (p) ] [ without time zone ] | 8 字节 | 日期和时间(无时区) | 4713 BC | 294276 AD | 1 毫秒 / 14 位 |
timestamp [ (p) ] with time zone | 8 字节 | 日期和时间,有时区 | 4713 BC | 294276 AD | 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 位 |
interval [ fields ] [ (p) ] | 12 字节 | 时间间隔 | -178000000 年 | 178000000 年 | 1 毫秒 / 14 位 |
注意
SQL要求只写timestamp
等效于timestamp without time zone
,并且PostgreSQL鼓励这种行为。timestamptz
被接受为timestamp with time zone
的一种简写,这是一种PostgreSQL的扩展。
time
、timestamp
和interval
接受一个可选的精度值 p
,这个精度值声明在秒域中小数点之后保留的位数。缺省情况下,在精度上没有明确的边界。p
允许的范围是从 0 到 6。
interval
类型有一个附加选项,它可以通过写下面之一的短语来限制存储的fields的集合:
1 2 3 4 5 6 7 8 9 10 11 12 13 | YEAR MONTH DAY HOUR MINUTE SECOND YEAR TO MONTH DAY TO HOUR DAY TO MINUTE DAY TO SECOND HOUR TO MINUTE HOUR TO SECOND MINUTE TO SECOND |
注意如果fields
和p
被指定,fields
必须包括SECOND
,因为精度只应用于秒。
类型time with time zone
是 SQL 标准定义的,但是该定义显示出了一些会影响可用性的性质。在大多数情况下, date
、time
、timestamp without time zone
和timestamp with time zone
的组合就应该能提供任何应用所需的全范围的日期/时间功能。
1. 日期/时间输入
日期和时间的输入可以接受几乎任何合理的格式,包括 ISO 8601、SQL-兼容的、传统POSTGRES的和其他的形式。 对于一些格式,日期输入里的日、月和年的顺序会让人混淆, 并且支持指定所预期的这些域的顺序。把DateStyle参数设置为MDY
,就是选择“月-日-年”的解释,设置为DMY
就是 “日-月-年”,而YMD
是 “年-月-日”。
PostgreSQL在处理日期/时间输入上比SQL标准要求的更灵活。 参阅附录 B获取关于日期/时间输入的准确的分析规则和可识别文本域,包括月份、星期几和时区。
请记住任何日期或者时间的文字输入需要由单引号包围,就象一个文本字符串一样。参考第 4.1.2.7 节获取更多信息。SQL要求下面的语法
1 | type [ (p) ] 'value' |
其中p
是一个可选的精度声明,它给出了在秒域中的小数位数目。精度可以被指定给time
、timestamp
和interval
类型,并且可以取从0到6的值。这允许前文所述的值。如果在一个常数声明中没有指定任何精度,它将默认取文字值的精度(但不能超过6位)。
1.1. 日期
表 8.10显示了date
类型可能的输入方式。
表 8.10. 日期输入
例子 | 描述 |
---|---|
1999-01-08 | ISO 8601; 任何模式下的1月8日 (推荐格式) |
January 8, 1999 | 在任何datestyle 输入模式下都无歧义 |
1/8/1999 | MDY 模式中的1月8日;DMY 模式中的8月1日 |
1/18/1999 | MDY 模式中的1月18日;在其他模式中被拒绝 |
01/02/03 | MDY 模式中的2003年1月2日; DMY 模式中的2003年2月1日; YMD 模式中的2001年2月3日 |
1999-Jan-08 | 任何模式下的1月8日 |
Jan-08-1999 | 任何模式下的1月8日 |
08-Jan-1999 | 任何模式下的1月8日 |
99-Jan-08 | YMD 模式中的1月8日,否则错误 |
08-Jan-99 | 1月8日,除了在YMD 模式中错误 |
Jan-08-99 | 1月8日,除了在YMD 模式中错误 |
19990108 | ISO 8601; 任何模式中的1999年1月8日 |
990108 | ISO 8601; 任何模式中的1999年1月8日 |
1999.008 | 年和一年中的日子 |
J2451187 | 儒略日期 |
January 8, 99 BC | 公元前99年 |
1.2. 时间
当日时间类型是time [ (*
p*) ] without time zone
和time [ (*
p*) ] with time zone
。 只写time
等效于time without time zone
。
这些类型的有效输入由当日时间后面跟着可选的时区组成(参阅表 8.11和表 8.12)。 如果在time without time zone
的输入中指定了时区,那么它会被无声地忽略。你也可以指定一个日期但是它会被忽略,除非你使用了一个涉及到夏令时规则的时区,例如America/New_York
。在这种情况下,为了判断是应用了标准时间还是夏令时时间,要求指定该日期。适当的时区偏移被记录在time with time zone
值中。
表 8.11. 时间输入