Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit6889537

Browse files
committed
Some small docs improvements motivated by reading the comments for the 7.4
7.4 interactive docs.
1 parentcb6eab7 commit6889537

File tree

2 files changed

+814
-780
lines changed

2 files changed

+814
-780
lines changed

‎doc/src/sgml/datatype.sgml

Lines changed: 60 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
<!--
2-
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.152 2004/12/23 05:37:39 tgl Exp $
2+
$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.153 2005/01/08 05:19:18 tgl Exp $
33
-->
44

55
<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
446446
The type <type>numeric</type> can store numbers with up to 1000
447447
digits of precision and perform calculations exactly. It is
448448
especially recommended for storing monetary amounts and other
449-
quantities where exactness is required. However,the
450-
<type>numeric</type>type is very slow compared to the
451-
floating-point types described in the next section.
449+
quantities where exactness is required. However,arithmetic on
450+
<type>numeric</type>values is very slow compared to the integer
451+
types, or to thefloating-point types described in the next section.
452452
</para>
453453

454454
<para>
@@ -464,7 +464,8 @@ $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.152 2004/12/23 05:37:39 tgl Ex
464464
</para>
465465

466466
<para>
467-
Both the precision and the scale of the numeric type can be
467+
Both the maximum precision and the maximum scale of a
468+
<type>numeric</type> column can be
468469
configured. To declare a column of type <type>numeric</type> use
469470
the syntax
470471
<programlisting>
@@ -492,10 +493,19 @@ NUMERIC
492493
</para>
493494

494495
<para>
495-
If the precision or scale of a value is greater than the declared
496-
precision or scale of a column, the system will attempt to round
497-
the value. If the value cannot be rounded so as to satisfy the
498-
declared limits, an error is raised.
496+
If the scale of a value to be stored is greater than the declared
497+
scale of the column, the system will round the value to the specified
498+
number of fractional digits. Then, if the number of digits to the
499+
left of the decimal point exceeds the declared precision minus the
500+
declared scale, an error is raised.
501+
</para>
502+
503+
<para>
504+
Numeric values are physically stored without any extra leading or
505+
trailing zeroes. Thus, the declared precision and scale of a column
506+
are maximums, not fixed allocations. (In this sense the <type>numeric</>
507+
type is more akin to <type>varchar(<replaceable>n</>)</type>
508+
than to <type>char(<replaceable>n</>)</type>.)
499509
</para>
500510

501511
<para>
@@ -1089,13 +1099,18 @@ SELECT b, char_length(b) FROM test2;
10891099

10901100
<para>
10911101
A binary string is a sequence of octets (or bytes). Binary
1092-
strings are distinguished fromcharacters strings by two
1102+
strings are distinguished fromcharacter strings by two
10931103
characteristics: First, binary strings specifically allow storing
10941104
octets of value zero and other <quote>non-printable</quote>
1095-
octets (defined as octets outside the range 32 to 126).
1105+
octets (usually, octets outside the range 32 to 126).
1106+
Character strings disallow zero octets, and also disallow any
1107+
other octet values and sequences of octet values that are invalid
1108+
according to the database's selected character set encoding.
10961109
Second, operations on binary strings process the actual bytes,
1097-
whereas the encoding and processing of character strings depends
1098-
on locale settings.
1110+
whereas the processing of character strings depends on locale settings.
1111+
In short, binary strings are appropriate for storing data that the
1112+
programmer thinks of as <quote>raw bytes</>, whereas character
1113+
strings are appropriate for storing text.
10991114
</para>
11001115

11011116
<para>
@@ -1254,7 +1269,7 @@ SELECT b, char_length(b) FROM test2;
12541269
<para>
12551270
The <acronym>SQL</acronym> standard defines a different binary
12561271
string type, called <type>BLOB</type> or <type>BINARY LARGE
1257-
OBJECT</type>. The input format is differentcompared to
1272+
OBJECT</type>. The input format is differentfrom
12581273
<type>bytea</type>, but the provided functions and operators are
12591274
mostly the same.
12601275
</para>
@@ -1295,7 +1310,9 @@ SELECT b, char_length(b) FROM test2;
12951310
<para>
12961311
<productname>PostgreSQL</productname> supports the full set of
12971312
<acronym>SQL</acronym> date and time types, shown in <xref
1298-
linkend="datatype-datetime-table">.
1313+
linkend="datatype-datetime-table">. The operations available
1314+
on these data types are described in
1315+
<xref linkend="functions-datetime">.
12991316
</para>
13001317

13011318
<table id="datatype-datetime-table">
@@ -1842,8 +1859,10 @@ January 8 04:05:06 1999 PST
18421859
are specially represented inside the system and will be displayed
18431860
the same way; but the others are simply notational shorthands
18441861
that will be converted to ordinary date/time values when read.
1845-
All of these values are treated as normal constants and need to be
1846-
written in single quotes.
1862+
(In particular, <literal>now</> and related strings are converted
1863+
to a specific time value as soon as they are read.)
1864+
All of these values need to be written in single quotes when used
1865+
as constants in SQL commands.
18471866
</para>
18481867

18491868
<table id="datatype-datetime-special-table">
@@ -1908,7 +1927,7 @@ January 8 04:05:06 1999 PST
19081927
<literal>CURRENT_DATE</literal>, <literal>CURRENT_TIME</literal>,
19091928
<literal>CURRENT_TIMESTAMP</literal>, <literal>LOCALTIME</literal>,
19101929
<literal>LOCALTIMESTAMP</literal>. The latter four accept an
1911-
optional precision specification. (Seealso<xref
1930+
optional precision specification. (See <xref
19121931
linkend="functions-datetime-current">.) Note however that these are
19131932
SQL functions and are <emphasis>not</> recognized as data input strings.
19141933
</para>
@@ -2265,7 +2284,7 @@ SELECT * FROM test1 WHERE a;
22652284
not work). This can be accomplished using the
22662285
<literal>CASE</literal> expression: <literal>CASE WHEN
22672286
<replaceable>boolval</replaceable> THEN 'value if true' ELSE
2268-
'value if false' END</literal>. Seealso<xref
2287+
'value if false' END</literal>. See <xref
22692288
linkend="functions-conditional">.
22702289
</para>
22712290
</tip>
@@ -2454,9 +2473,9 @@ SELECT * FROM test1 WHERE a;
24542473
<para>
24552474
Paths are represented by lists of connected points. Paths can be
24562475
<firstterm>open</firstterm>, where
2457-
the first and last points in the list are not connected, or
2476+
the first and last points in the list are notconsideredconnected, or
24582477
<firstterm>closed</firstterm>,
2459-
where the first and last points are connected.
2478+
where the first and last points areconsideredconnected.
24602479
</para>
24612480

24622481
<para>
@@ -2558,7 +2577,7 @@ SELECT * FROM test1 WHERE a;
25582577
is preferable to use these types instead of plain text types to store
25592578
network addresses, because
25602579
these types offer input error checking and several specialized
2561-
operators and functions.
2580+
operators and functions (see <xref linkend="functions-net">).
25622581
</para>
25632582

25642583
<table tocentry="1" id="datatype-net-types-table">
@@ -3006,12 +3025,25 @@ SELECT * FROM test;
30063025
for specialized input and output routines. These routines are able
30073026
to accept and display symbolic names for system objects, rather than
30083027
the raw numeric value that type <type>oid</> would use. The alias
3009-
types allow simplified lookup of OID values for objects: for example,
3010-
one may write <literal>'mytable'::regclass</> to get the OID of table
3011-
<literal>mytable</>, rather than <literal>SELECT oid FROM pg_class WHERE
3012-
relname = 'mytable'</>. (In reality, a much more complicated <command>SELECT</> would
3013-
be needed to deal with selecting the right OID when there are multiple
3014-
tables named <literal>mytable</> in different schemas.)
3028+
types allow simplified lookup of OID values for objects. For example,
3029+
to examine the <structname>pg_attribute</> rows related to a table
3030+
<literal>mytable</>, one could write
3031+
<programlisting>
3032+
SELECT * FROM pg_attribute WHERE attrelid = 'mytable'::regclass;
3033+
</programlisting>
3034+
rather than
3035+
<programlisting>
3036+
SELECT * FROM pg_attribute
3037+
WHERE attrelid = (SELECT oid FROM pg_class WHERE relname = 'mytable');
3038+
</programlisting>
3039+
While that doesn't look all that bad by itself, it's still oversimplified.
3040+
A far more complicated sub-select would be needed to
3041+
select the right OID if there are multiple tables named
3042+
<literal>mytable</> in different schemas.
3043+
The <type>regclass</> input converter handles the table lookup according
3044+
to the schema path setting, and so it does the <quote>right thing</>
3045+
automatically. Similarly, casting a table's OID to
3046+
<type>regclass</> is handy for symbolic display of a numeric OID.
30153047
</para>
30163048

30173049
<table id="datatype-oid-table">

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp