# 8.1.数字类型
数字类型由两字节、四字节和八字节整数、四字节和八字节浮点数以及可选精度小数组成。表8.2列出可用的类型。
表8.2.数字类型
名称 | 存储大小 | 描述 | 范围 |
---|---|---|---|
短整型 | 2字节 | 小范围整数 | -32768至+32767 |
整数 | 4字节 | 整数的典型选择 | -2147483648至+2147483647 |
比基特 | 8字节 | 大范围整数 | -9223372036854775808至+9223372036854775807 |
十进制的 | 变量 | 用户指定的精度,精确 | 小数点前最多131072位;小数点后最多16383位 |
数字的 | 变量 | 用户指定的精度,精确 | 小数点前最多131072位;小数点后最多16383位 |
真实的 | 4字节 | 可变精度,不精确 | 6位小数精度 |
双精度 | 8字节 | 可变精度,不精确 | 15位小数精度 |
smallserial | 2字节 | 小的自增整数 | 1至32767 |
电视连续剧 | 4字节 | 自动递增整数 | 1至2147483647 |
大系列 | 8字节 | 大的自动递增整数 | 1至9223372036854775807 |
数值类型的常量语法如中所述第4.1.2节.数字类型有一整套相应的算术运算符和函数。提到第九章了解更多信息。以下各节详细介绍了这些类型。
# 8.1.1.整数类型
类型短整型
, 整数
和比基特
存储各种范围的整数,即不含小数部分的数字。尝试存储超出允许范围的值将导致错误。
类型整数
是常见的选择,因为它提供了范围、存储大小和性能之间的最佳平衡。这个短整型
类型通常仅在磁盘空间特别大的情况下使用。这个比基特
类型设计为在以下情况下使用:整数
类型不足。
SQL只指定整数类型整数
(或智力
), 短整型
和比基特
.类型名称int2
, int4
和int8
是扩展,其他一些SQL数据库系统也使用这些扩展。
# 8.1.2.任意精度数字
类型数字的
可以存储大量数字的数字。特别推荐用于存储货币数量和其他需要精确的数量。计算数字的
如果可能,值会产生精确的结果,例如加法、减法、乘法。然而数字的
与整数类型或下一节中描述的浮点类型相比,值的速度非常慢。
我们使用以下术语:精确一个数字的
是整数中有效位数的总数,即小数点两侧的位数。这个规模一个数字的
小数点右侧小数部分的小数位数计数。所以数字23.5141的精度为6,刻度为4.整数可以被认为具有零的刻度。
a的最大精度和最大刻度数字的
可以配置列。声明类型为的列的步骤数字的
使用以下语法:
NUMERIC(precision, scale)
精度必须为正,刻度为零或正。或者:
NUMERIC(precision)
选择0的比例。具体说明:
NUMERIC
在没有任何精度或比例的情况下,会创建一个“无约束数值”列,其中可以存储任意长度的数值,直到实现限制。此类列不会将输入值强制设置为任何特定的比例数字的
具有声明比例的列将强制输入值为该比例。(SQL标准要求默认刻度为0,即强制为整数精度。我们发现这有点无用。如果您担心可移植性,请始终明确指定精度和刻度。)
# 笔记
可在中显式指定的最大精度数字的
类型声明为1000.无拘无束的人数字的
列受中所述的限制表8.2.
如果要存储的值的小数位数大于列的声明小数位数,系统会将该值四舍五入到指定的小数位数。然后,如果小数点左边的位数超过声明的精度减去声明的小数位数,则会产生错误。
数值是物理存储的,没有任何额外的前导或尾随零。因此,列的声明精度和比例是最大值,而不是固定的分配。(从这个意义上说数字的
类型更类似于瓦尔查尔(*
n*)
而不是炭(*
n*)
)实际存储需求是每组四位十进制数字需要两个字节,外加三到八个字节的开销。
除了普通的数值外数字的
类型有几个特殊值:
无穷
-无穷大
楠
这些是根据IEEE 754标准改编的,分别代表“无限”、“负无限”和“非数字”。例如,在SQL命令中将这些值作为常量写入时,必须在其周围加引号更新表格集x='-Infinity'
。在输入时,这些字符串以不区分大小写的方式识别。无穷大值也可以拼写inf
和-inf
.
无穷大值的行为符合数学期望。例如无穷
加上任何有限值等于无穷
,以及无穷
加无穷
; 但是无穷
减无穷
产量楠
(不是数字),因为它没有明确的解释。请注意,无穷大只能存储在无约束的空间中数字的
列,因为它名义上超过了任何有限精度限制。
这个楠
(不是数字)值用于表示未定义的计算结果。一般来说,任何带有楠
投入会产生另一个结果楠
唯一的例外情况是,如果操作的其他输入是相同的,那么楠
被任何有限或无限的数值所取代;然后,该输出值用于楠
也(这一原则的一个例子是楠
将功率提高到零会产生一个。)
# 笔记
在大多数“非数字”概念的实现中,楠
不被视为等于任何其他数值(包括楠
).为了允许数字的
要在基于树的索引中排序和使用的值,PostgreSQL楠
值相等,且大于所有非-楠
价值观
类型十进制的
和数字的
它们是等价的。这两种类型都是SQL标准的一部分。
对值进行舍入时数字的
打字使领带远离零度,而(在大多数机器上)在真实的
和双精度
键入最接近的偶数。例如:
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
### 8.1.3. Floating-Point Types
[]()[]()[]()[]()[]()
The data types `real` and `double precision` are inexact, variable-precision numeric types. On all currently supported platforms, these types are implementations of IEEE Standard 754 for Binary Floating-Point Arithmetic (single and double precision, respectively), to the extent that the underlying processor, operating system, and compiler support it.
Inexact means that some values cannot be converted exactly to the internal format and are stored as approximations, so that storing and retrieving a value might show slight discrepancies. Managing these errors and how they propagate through calculations is the subject of an entire branch of mathematics and computer science and will not be discussed here, except for the following points:
* If you require exact storage and calculations (such as for monetary amounts), use the `numeric` type instead.
* If you want to do complicated calculations with these types for anything important, especially if you rely on certain behavior in boundary cases (infinity, underflow), you should evaluate the implementation carefully.
* Comparing two floating-point values for equality might not always work as expected.
On all currently supported platforms, the `real` type has a range of around 1E-37 to 1E+37 with a precision of at least 6 decimal digits. The `double precision` type has a range of around 1E-307 to 1E+308 with a precision of at least 15 digits. Values that are too large or too small will cause an error. Rounding might take place if the precision of an input number is too high. Numbers too close to zero that are not representable as distinct from zero will cause an underflow error.
By default, floating point values are output in text form in their shortest precise decimal representation; the decimal value produced is closer to the true stored binary value than to any other value representable in the same binary precision. (However, the output value is currently never *exactly* midway between two representable values, in order to avoid a widespread bug where input routines do not properly respect the round-to-nearest-even rule.) This value will use at most 17 significant decimal digits for `float8` values, and at most 9 digits for `float4` values.
### Note
This shortest-precise output format is much faster to generate than the historical rounded format.
For compatibility with output generated by older versions of PostgreSQL, and to allow the output precision to be reduced, the [extra\_float\_digits](runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS) parameter can be used to select rounded decimal output instead. Setting a value of 0 restores the previous default of rounding the value to 6 (for `float4`) or 15 (for `float8`) significant decimal digits. Setting a negative value reduces the number of digits further; for example -2 would round output to 4 or 13 digits respectively.
Any value of [extra\_float\_digits](runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS) greater than 0 selects the shortest-precise format.
### Note
Applications that wanted precise values have historically had to set [extra\_float\_digits](runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS) to 3 to obtain them. For maximum compatibility between versions, they should continue to do so.
[]()[]()
In addition to ordinary numeric values, the floating-point types have several special values:
`Infinity`
`-Infinity`
`NaN`
These represent the IEEE 754 special values “infinity”, “negative infinity”, and “not-a-number”, respectively. When writing these values as constants in an SQL command, you must put quotes around them, for example `UPDATE table SET x = '-Infinity'`. On input, these strings are recognized in a case-insensitive manner. The infinity values can alternatively be spelled `inf` and `-inf`.
### Note
IEEE 754 specifies that `NaN` should not compare equal to any other floating-point value (including `NaN`). In order to allow floating-point values to be sorted and used in tree-based indexes, PostgreSQL treats `NaN` values as equal, and greater than all non-`NaN` values.
PostgreSQL also supports the SQL-standard notations `float` and `float(*`p`*)` for specifying inexact numeric types. Here, *`p`* specifies the minimum acceptable precision in *binary* digits. PostgreSQL accepts `float(1)` to `float(24)` as selecting the `real` type, while `float(25)` to `float(53)` select `double precision`. Values of *`p`* outside the allowed range draw an error. `float` with no precision specified is taken to mean `double precision`.
### 8.1.4. Serial Types
[]()[]()[]()[]()[]()[]()[]()[]()
### Note
This section describes a PostgreSQL-specific way to create an autoincrementing column. Another way is to use the SQL-standard identity column feature, described at [CREATE TABLE](sql-createtable.html).
The data types `smallserial`, `serial` and `bigserial` are not true types, but merely a notational convenience for creating unique identifier columns (similar to the `AUTO_INCREMENT` property supported by some other databases). In the current implementation, specifying:
创建表tablename(colname SERIAL);
is equivalent to specifying:
创建序列tablename_colname_seq作为整数;创建表tablename(colname integer NOT NULL默认值nextval('tablename_colname_seq');更改tablename拥有的序列tablename_colname_seq。colname;
Thus, we have created an integer column and arranged for its default values to be assigned from a sequence generator. A `NOT NULL` constraint is applied to ensure that a null value cannot be inserted. (In most cases you would also want to attach a `UNIQUE` or `PRIMARY KEY` constraint to prevent duplicate values from being inserted by accident, but this is not automatic.) Lastly, the sequence is marked as “owned by” the column, so that it will be dropped if the column or table is dropped.
### Note
Because `smallserial`, `serial` and `bigserial` are implemented using sequences, there may be "holes" or gaps in the sequence of values which appears in the column, even if no rows are ever deleted. A value allocated from the sequence is still "used up" even if a row containing that value is never successfully inserted into the table column. This may happen, for example, if the inserting transaction rolls back. See `nextval()` in [Section 9.17](functions-sequence.html) for details.
To insert the next value of the sequence into the `serial` column, specify that the `serial` column should be assigned its default value. This can be done either by excluding the column from the list of columns in the `INSERT` statement, or through the use of the `DEFAULT` key word.
The type names `serial` and `serial4` are equivalent: both create `integer` columns. The type names `bigserial` and `serial8` work the same way, except that they create a `bigint` column. `bigserial` should be used if you anticipate the use of more than 2<sup>31</sup> identifiers over the lifetime of the table. The type names `smallserial` and `serial2` also work the same way, except that they create a `smallint` column.
The sequence created for a `serial` column is automatically dropped when the owning column is dropped. You can drop the sequence without dropping the column, but this will force removal of the column default expression.