Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
6889537c
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
6889537c
编写于
1月 08, 2005
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Some small docs improvements motivated by reading the comments for the 7.4
7.4 interactive docs.
上级
cb6eab78
变更
2
展开全部
隐藏空白更改
内联
并排
Showing
2 changed file
with
814 addition
and
780 deletion
+814
-780
doc/src/sgml/datatype.sgml
doc/src/sgml/datatype.sgml
+60
-28
doc/src/sgml/func.sgml
doc/src/sgml/func.sgml
+754
-752
未找到文件。
doc/src/sgml/datatype.sgml
浏览文件 @
6889537c
<!--
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.15
2 2004/12/23 05:37:39
tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.15
3 2005/01/08 05:19:18
tgl Exp $
-->
<chapter id="datatype">
...
...
@@ -446,9 +446,9 @@ $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.152 2004/12/23 05:37:39 tgl Ex
The type <type>numeric</type> can store numbers with up to 1000
digits of precision and perform calculations exactly. It is
especially recommended for storing monetary amounts and other
quantities where exactness is required. However,
the
<type>numeric</type>
type is very slow compared to the
floating-point types described in the next section.
quantities where exactness is required. However,
arithmetic on
<type>numeric</type>
values is very slow compared to the integer
types, or to the
floating-point types described in the next section.
</para>
<para>
...
...
@@ -464,7 +464,8 @@ $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.152 2004/12/23 05:37:39 tgl Ex
</para>
<para>
Both the precision and the scale of the numeric type can be
Both the maximum precision and the maximum scale of a
<type>numeric</type> column can be
configured. To declare a column of type <type>numeric</type> use
the syntax
<programlisting>
...
...
@@ -492,10 +493,19 @@ NUMERIC
</para>
<para>
If the precision or scale of a value is greater than the declared
precision or scale of a column, the system will attempt to round
the value. If the value cannot be rounded so as to satisfy the
declared limits, an error is raised.
If the scale of a value to be stored is greater than the declared
scale of the column, the system will round the value to the specified
number of fractional digits. Then, if the number of digits to the
left of the decimal point exceeds the declared precision minus the
declared scale, an error is raised.
</para>
<para>
Numeric values are physically stored without any extra leading or
trailing zeroes. Thus, the declared precision and scale of a column
are maximums, not fixed allocations. (In this sense the <type>numeric</>
type is more akin to <type>varchar(<replaceable>n</>)</type>
than to <type>char(<replaceable>n</>)</type>.)
</para>
<para>
...
...
@@ -1089,13 +1099,18 @@ SELECT b, char_length(b) FROM test2;
<para>
A binary string is a sequence of octets (or bytes). Binary
strings are distinguished from character
s
strings by two
strings are distinguished from character strings by two
characteristics: First, binary strings specifically allow storing
octets of value zero and other <quote>non-printable</quote>
octets (defined as octets outside the range 32 to 126).
octets (usually, octets outside the range 32 to 126).
Character strings disallow zero octets, and also disallow any
other octet values and sequences of octet values that are invalid
according to the database's selected character set encoding.
Second, operations on binary strings process the actual bytes,
whereas the encoding and processing of character strings depends
on locale settings.
whereas the processing of character strings depends on locale settings.
In short, binary strings are appropriate for storing data that the
programmer thinks of as <quote>raw bytes</>, whereas character
strings are appropriate for storing text.
</para>
<para>
...
...
@@ -1254,7 +1269,7 @@ SELECT b, char_length(b) FROM test2;
<para>
The <acronym>SQL</acronym> standard defines a different binary
string type, called <type>BLOB</type> or <type>BINARY LARGE
OBJECT</type>. The input format is different compared to
OBJECT</type>. The input format is different from
<type>bytea</type>, but the provided functions and operators are
mostly the same.
</para>
...
...
@@ -1295,7 +1310,9 @@ SELECT b, char_length(b) FROM test2;
<para>
<productname>PostgreSQL</productname> supports the full set of
<acronym>SQL</acronym> date and time types, shown in <xref
linkend="datatype-datetime-table">.
linkend="datatype-datetime-table">. The operations available
on these data types are described in
<xref linkend="functions-datetime">.
</para>
<table id="datatype-datetime-table">
...
...
@@ -1842,8 +1859,10 @@ January 8 04:05:06 1999 PST
are specially represented inside the system and will be displayed
the same way; but the others are simply notational shorthands
that will be converted to ordinary date/time values when read.
All of these values are treated as normal constants and need to be
written in single quotes.
(In particular, <literal>now</> and related strings are converted
to a specific time value as soon as they are read.)
All of these values need to be written in single quotes when used
as constants in SQL commands.
</para>
<table id="datatype-datetime-special-table">
...
...
@@ -1908,7 +1927,7 @@ January 8 04:05:06 1999 PST
<literal>CURRENT_DATE</literal>, <literal>CURRENT_TIME</literal>,
<literal>CURRENT_TIMESTAMP</literal>, <literal>LOCALTIME</literal>,
<literal>LOCALTIMESTAMP</literal>. The latter four accept an
optional precision specification. (See
also
<xref
optional precision specification. (See <xref
linkend="functions-datetime-current">.) Note however that these are
SQL functions and are <emphasis>not</> recognized as data input strings.
</para>
...
...
@@ -2265,7 +2284,7 @@ SELECT * FROM test1 WHERE a;
not work). This can be accomplished using the
<literal>CASE</literal> expression: <literal>CASE WHEN
<replaceable>boolval</replaceable> THEN 'value if true' ELSE
'value if false' END</literal>. See
also
<xref
'value if false' END</literal>. See <xref
linkend="functions-conditional">.
</para>
</tip>
...
...
@@ -2454,9 +2473,9 @@ SELECT * FROM test1 WHERE a;
<para>
Paths are represented by lists of connected points. Paths can be
<firstterm>open</firstterm>, where
the first and last points in the list are not connected, or
the first and last points in the list are not con
sidered con
nected, or
<firstterm>closed</firstterm>,
where the first and last points are connected.
where the first and last points are con
sidered con
nected.
</para>
<para>
...
...
@@ -2558,7 +2577,7 @@ SELECT * FROM test1 WHERE a;
is preferable to use these types instead of plain text types to store
network addresses, because
these types offer input error checking and several specialized
operators and functions.
operators and functions
(see <xref linkend="functions-net">)
.
</para>
<table tocentry="1" id="datatype-net-types-table">
...
...
@@ -3006,12 +3025,25 @@ SELECT * FROM test;
for specialized input and output routines. These routines are able
to accept and display symbolic names for system objects, rather than
the raw numeric value that type <type>oid</> would use. The alias
types allow simplified lookup of OID values for objects: for example,
one may write <literal>'mytable'::regclass</> to get the OID of table
<literal>mytable</>, rather than <literal>SELECT oid FROM pg_class WHERE
relname = 'mytable'</>. (In reality, a much more complicated <command>SELECT</> would
be needed to deal with selecting the right OID when there are multiple
tables named <literal>mytable</> in different schemas.)
types allow simplified lookup of OID values for objects. For example,
to examine the <structname>pg_attribute</> rows related to a table
<literal>mytable</>, one could write
<programlisting>
SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;
</programlisting>
rather than
<programlisting>
SELECT * FROM pg_attribute
WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');
</programlisting>
While that doesn't look all that bad by itself, it's still oversimplified.
A far more complicated sub-select would be needed to
select the right OID if there are multiple tables named
<literal>mytable</> in different schemas.
The <type>regclass</> input converter handles the table lookup according
to the schema path setting, and so it does the <quote>right thing</>
automatically. Similarly, casting a table's OID to
<type>regclass</> is handy for symbolic display of a numeric OID.
</para>
<table id="datatype-oid-table">
...
...
doc/src/sgml/func.sgml
浏览文件 @
6889537c
此差异已折叠。
点击以展开。
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录