|
|
|
@ -1,5 +1,5 @@ |
|
|
|
<!-- |
|
|
|
<!-- |
|
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.107 2002/11/11 20:14:02 petere Exp $ |
|
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.108 2002/11/15 03:11:15 momjian Exp $ |
|
|
|
--> |
|
|
|
--> |
|
|
|
|
|
|
|
|
|
|
|
<chapter id="datatype"> |
|
|
|
<chapter id="datatype"> |
|
|
|
@ -245,14 +245,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.107 2002/11/11 20:14:02 p |
|
|
|
<note> |
|
|
|
<note> |
|
|
|
<title>Compatibility</title> |
|
|
|
<title>Compatibility</title> |
|
|
|
<para> |
|
|
|
<para> |
|
|
|
The following types (or spellings thereof) are specified by SQL: |
|
|
|
The following types (or spellings thereof) are specified by |
|
|
|
<type>bit</type>, <type>bit varying</type>, <type>boolean</type>, |
|
|
|
<acronym>SQL</acronym>: <type>bit</type>, <type>bit |
|
|
|
<type>char</type>, <type>character</type>, <type>character |
|
|
|
varying</type>, <type>boolean</type>, <type>char</type>, |
|
|
|
varying</type>, <type>varchar</type>, <type>date</type>, |
|
|
|
<type>character</type>, <type>character varying</type>, |
|
|
|
<type>double precision</type>, <type>integer</type>, |
|
|
|
<type>varchar</type>, <type>date</type>, <type>double |
|
|
|
<type>interval</type>, <type>numeric</type>, <type>decimal</type>, |
|
|
|
precision</type>, <type>integer</type>, <type>interval</type>, |
|
|
|
<type>real</type>, <type>smallint</type>, <type>time</type>, |
|
|
|
<type>numeric</type>, <type>decimal</type>, <type>real</type>, |
|
|
|
<type>timestamp</type> (both with or without time zone). |
|
|
|
<type>smallint</type>, <type>time</type>, <type>timestamp</type> |
|
|
|
|
|
|
|
(both with or without time zone). |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
</note> |
|
|
|
</note> |
|
|
|
|
|
|
|
|
|
|
|
@ -464,11 +465,12 @@ $Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.107 2002/11/11 20:14:02 p |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
SQL only specifies the integer types <type>integer</type> (or |
|
|
|
<acronym>SQL</acronym> only specifies the integer types |
|
|
|
<type>int</type>) and <type>smallint</type>. The type |
|
|
|
<type>integer</type> (or <type>int</type>) and |
|
|
|
<type>bigint</type>, and the type names <type>int2</type>, |
|
|
|
<type>smallint</type>. The type <type>bigint</type>, and the |
|
|
|
<type>int4</type>, and <type>int8</type> are extensions, which |
|
|
|
type names <type>int2</type>, <type>int4</type>, and |
|
|
|
are shared with various other SQL database systems. |
|
|
|
<type>int8</type> are extensions, which are shared with various |
|
|
|
|
|
|
|
other <acronym>SQL</acronym> database systems. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
<note> |
|
|
|
@ -536,13 +538,15 @@ NUMERIC(<replaceable>precision</replaceable>) |
|
|
|
NUMERIC |
|
|
|
NUMERIC |
|
|
|
</programlisting> |
|
|
|
</programlisting> |
|
|
|
without any precision or scale creates a column in which numeric |
|
|
|
without any precision or scale creates a column in which numeric |
|
|
|
values of any precision and scale can be stored, up to the implementation |
|
|
|
values of any precision and scale can be stored, up to the |
|
|
|
limit on precision. A column of this kind will not coerce input |
|
|
|
implementation limit on precision. A column of this kind will |
|
|
|
values to any particular scale, whereas <type>numeric</type> columns |
|
|
|
not coerce input values to any particular scale, whereas |
|
|
|
with a declared scale will coerce input values to that scale. |
|
|
|
<type>numeric</type> columns with a declared scale will coerce |
|
|
|
(The SQL standard requires a default scale of 0, i.e., coercion to |
|
|
|
input values to that scale. (The <acronym>SQL</acronym> standard |
|
|
|
integer precision. We find this a bit useless. If you're concerned about |
|
|
|
requires a default scale of 0, i.e., coercion to integer |
|
|
|
portability, always specify the precision and scale explicitly.) |
|
|
|
precision. We find this a bit useless. If you're concerned |
|
|
|
|
|
|
|
about portability, always specify the precision and scale |
|
|
|
|
|
|
|
explicitly.) |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
@ -554,7 +558,8 @@ NUMERIC |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
The types <type>decimal</type> and <type>numeric</type> are |
|
|
|
The types <type>decimal</type> and <type>numeric</type> are |
|
|
|
equivalent. Both types are part of the SQL standard. |
|
|
|
equivalent. Both types are part of the <acronym>SQL</acronym> |
|
|
|
|
|
|
|
standard. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
</sect2> |
|
|
|
</sect2> |
|
|
|
|
|
|
|
|
|
|
|
@ -806,7 +811,8 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> ( |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
<xref linkend="datatype-character-table"> shows the |
|
|
|
<xref linkend="datatype-character-table"> shows the |
|
|
|
general-purpose character types available in PostgreSQL. |
|
|
|
general-purpose character types available in |
|
|
|
|
|
|
|
<productname>PostgreSQL</productname>. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
@ -818,11 +824,12 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> ( |
|
|
|
longer string into a column of these types will result in an |
|
|
|
longer string into a column of these types will result in an |
|
|
|
error, unless the excess characters are all spaces, in which case |
|
|
|
error, unless the excess characters are all spaces, in which case |
|
|
|
the string will be truncated to the maximum length. (This |
|
|
|
the string will be truncated to the maximum length. (This |
|
|
|
somewhat bizarre exception is required by the SQL standard.) If |
|
|
|
somewhat bizarre exception is required by the |
|
|
|
the string to be stored is shorter than the declared length, |
|
|
|
<acronym>SQL</acronym> standard.) If the string to be stored is |
|
|
|
values of type <type>character</type> will be space-padded; values |
|
|
|
shorter than the declared length, values of type |
|
|
|
of type <type>character varying</type> will simply store the |
|
|
|
<type>character</type> will be space-padded; values of type |
|
|
|
shorter string. |
|
|
|
<type>character varying</type> will simply store the shorter |
|
|
|
|
|
|
|
string. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
<note> |
|
|
|
@ -831,7 +838,8 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> ( |
|
|
|
<type>character(<replaceable>n</>)</type> or <type>character |
|
|
|
<type>character(<replaceable>n</>)</type> or <type>character |
|
|
|
varying(<replaceable>n</>)</type>, then an overlength value will |
|
|
|
varying(<replaceable>n</>)</type>, then an overlength value will |
|
|
|
be truncated to <replaceable>n</> characters without raising an |
|
|
|
be truncated to <replaceable>n</> characters without raising an |
|
|
|
error. (This too is required by the SQL standard.) |
|
|
|
error. (This too is required by the <acronym>SQL</acronym> |
|
|
|
|
|
|
|
standard.) |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
</note> |
|
|
|
</note> |
|
|
|
|
|
|
|
|
|
|
|
@ -859,8 +867,9 @@ CREATE TABLE <replaceable class="parameter">tablename</replaceable> ( |
|
|
|
more general <type>text</type> type, which stores strings of any |
|
|
|
more general <type>text</type> type, which stores strings of any |
|
|
|
length. Unlike <type>character varying</type>, <type>text</type> |
|
|
|
length. Unlike <type>character varying</type>, <type>text</type> |
|
|
|
does not require an explicit declared upper limit on the size of |
|
|
|
does not require an explicit declared upper limit on the size of |
|
|
|
the string. Although the type <type>text</type> is not in the SQL |
|
|
|
the string. Although the type <type>text</type> is not in the |
|
|
|
standard, many other RDBMS packages have it as well. |
|
|
|
<acronym>SQL</acronym> standard, many other RDBMS packages have it |
|
|
|
|
|
|
|
as well. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
@ -1125,12 +1134,12 @@ SELECT b, char_length(b) FROM test2; |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
To use the <type>bytea</type> escaped octet notation, string |
|
|
|
To use the <type>bytea</type> escaped octet notation, string |
|
|
|
literals (input strings) must contain two backslashes due because |
|
|
|
literals (input strings) must contain two backslashes because they |
|
|
|
they must pass through two parsers in the PostgreSQL server. The |
|
|
|
must pass through two parsers in the <productname>PostgreSQL</> |
|
|
|
first backslash is interpreted as an escape character by the |
|
|
|
server. The first backslash is interpreted as an escape character |
|
|
|
string-literal parser, and therefore is consumed, leaving the |
|
|
|
by the string-literal parser, and therefore is consumed, leaving |
|
|
|
characters that follow. The remaining backslash is recognized by |
|
|
|
the characters that follow. The remaining backslash is recognized |
|
|
|
the <type>bytea</type> input function as the prefix of a three |
|
|
|
by the <type>bytea</type> input function as the prefix of a three |
|
|
|
digit octal value. For example, a string literal passed to the |
|
|
|
digit octal value. For example, a string literal passed to the |
|
|
|
backend as <literal>'\\001'</literal> becomes |
|
|
|
backend as <literal>'\\001'</literal> becomes |
|
|
|
<literal>'\001'</literal> after passing through the string-literal |
|
|
|
<literal>'\001'</literal> after passing through the string-literal |
|
|
|
@ -1170,21 +1179,22 @@ SELECT b, char_length(b) FROM test2; |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
Depending on the front end to PostgreSQL you use, you may have |
|
|
|
Depending on the front end to <productname>PostgreSQL</> you use, |
|
|
|
additional work to do in terms of escaping and unescaping |
|
|
|
you may have additional work to do in terms of escaping and |
|
|
|
<type>bytea</type> strings. For example, you may also have to escape |
|
|
|
unescaping <type>bytea</type> strings. For example, you may also |
|
|
|
line feeds and carriage returns if your interface automatically |
|
|
|
have to escape line feeds and carriage returns if your interface |
|
|
|
translates these. Or you may have to double up on backslashes if |
|
|
|
automatically translates these. Or you may have to double up on |
|
|
|
the parser for your language or choice also treats them as an |
|
|
|
backslashes if the parser for your language or choice also treats |
|
|
|
escape character. |
|
|
|
them as an escape character. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
The SQL standard defines a different binary string type, called |
|
|
|
The <acronym>SQL</acronym> standard defines a different binary |
|
|
|
<type>BLOB</type> or <type>BINARY LARGE OBJECT</type>. The input |
|
|
|
string type, called <type>BLOB</type> or <type>BINARY LARGE |
|
|
|
format is different compared to <type>bytea</type>, but the |
|
|
|
OBJECT</type>. The input format is different compared to |
|
|
|
provided functions and operators are mostly the same. |
|
|
|
<type>bytea</type>, but the provided functions and operators are |
|
|
|
</para> |
|
|
|
mostly the same. |
|
|
|
|
|
|
|
</para> |
|
|
|
</sect1> |
|
|
|
</sect1> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@ -1781,11 +1791,12 @@ January 8 04:05:06 1999 PST |
|
|
|
Output formats can be set to one of the four styles ISO 8601, |
|
|
|
Output formats can be set to one of the four styles ISO 8601, |
|
|
|
<acronym>SQL</acronym> (Ingres), traditional PostgreSQL, and |
|
|
|
<acronym>SQL</acronym> (Ingres), traditional PostgreSQL, and |
|
|
|
German, using the <command>SET DateStyle</command>. The default |
|
|
|
German, using the <command>SET DateStyle</command>. The default |
|
|
|
is the <acronym>ISO</acronym> format. (The SQL standard requires |
|
|
|
is the <acronym>ISO</acronym> format. (The |
|
|
|
the use of the ISO 8601 format. The name of the |
|
|
|
<acronym>SQL</acronym> standard requires the use of the ISO 8601 |
|
|
|
<quote>SQL</quote> output format is a historical accident.) |
|
|
|
format. The name of the <quote>SQL</quote> output format is a |
|
|
|
<xref linkend="datatype-datetime-output-table"> shows examples of |
|
|
|
historical accident.) <xref |
|
|
|
each output style. The output of the <type>date</type> and |
|
|
|
linkend="datatype-datetime-output-table"> shows examples of each |
|
|
|
|
|
|
|
output style. The output of the <type>date</type> and |
|
|
|
<type>time</type> types is of course only the date or time part |
|
|
|
<type>time</type> types is of course only the date or time part |
|
|
|
in accordance with the given examples. |
|
|
|
in accordance with the given examples. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
@ -1920,34 +1931,34 @@ January 8 04:05:06 1999 PST |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
To address these difficulties, we recommend using date/time |
|
|
|
To address these difficulties, we recommend using date/time types |
|
|
|
types that contain both date and time when using time zones. We |
|
|
|
that contain both date and time when using time zones. We |
|
|
|
recommend <emphasis>not</emphasis> using the type <type>time |
|
|
|
recommend <emphasis>not</emphasis> using the type <type>time with |
|
|
|
with time zone</type> (though it is supported by |
|
|
|
time zone</type> (though it is supported by |
|
|
|
<productname>PostgreSQL</productname> for legacy applications and |
|
|
|
<productname>PostgreSQL</productname> for legacy applications and |
|
|
|
for compatibility with other SQL implementations). |
|
|
|
for compatibility with other <acronym>SQL</acronym> |
|
|
|
<productname>PostgreSQL</productname> |
|
|
|
implementations). <productname>PostgreSQL</productname> assumes |
|
|
|
assumes your local time zone for any type containing only |
|
|
|
your local time zone for any type containing only date or |
|
|
|
date or time. Further, time zone support is derived from |
|
|
|
time. Further, time zone support is derived from the underlying |
|
|
|
the underlying operating system |
|
|
|
operating system time-zone capabilities, and hence can handle |
|
|
|
time-zone capabilities, and hence can handle daylight-saving time |
|
|
|
daylight-saving time and other expected behavior. |
|
|
|
and other expected behavior. |
|
|
|
|
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
<productname>PostgreSQL</productname> obtains time-zone support |
|
|
|
<productname>PostgreSQL</productname> obtains time-zone support |
|
|
|
from the underlying operating system for dates between 1902 and |
|
|
|
from the underlying operating system for dates between 1902 and |
|
|
|
2038 (near the typical date limits for Unix-style |
|
|
|
2038 (near the typical date limits for Unix-style |
|
|
|
systems). Outside of this range, all dates are assumed to be |
|
|
|
systems). Outside of this range, all dates are assumed to be |
|
|
|
specified and used in Universal Coordinated Time (UTC). |
|
|
|
specified and used in Universal Coordinated Time |
|
|
|
|
|
|
|
(<acronym>UTC</acronym>). |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
All dates and times are stored internally in UTC, |
|
|
|
All dates and times are stored internally in |
|
|
|
traditionally known as Greenwich Mean Time (GMT). |
|
|
|
<acronym>UTC</acronym>, traditionally known as Greenwich Mean |
|
|
|
Times are converted to local time on the database server before being |
|
|
|
Time (<acronym>GMT</acronym>). Times are converted to local time |
|
|
|
sent to the client frontend, hence by default are in the server |
|
|
|
on the database server before being sent to the client frontend, |
|
|
|
time zone. |
|
|
|
hence by default are in the server time zone. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
@ -1993,8 +2004,8 @@ January 8 04:05:06 1999 PST |
|
|
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
<note> |
|
|
|
<para> |
|
|
|
<para> |
|
|
|
If an invalid time zone is specified, |
|
|
|
If an invalid time zone is specified, the time zone becomes |
|
|
|
the time zone becomes GMT (on most systems anyway). |
|
|
|
<acronym>UTC</acronym> (on most systems anyway). |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
</note> |
|
|
|
</note> |
|
|
|
|
|
|
|
|
|
|
|
@ -2124,8 +2135,9 @@ SELECT * FROM test1 WHERE a; |
|
|
|
<para> |
|
|
|
<para> |
|
|
|
Geometric data types represent two-dimensional spatial |
|
|
|
Geometric data types represent two-dimensional spatial |
|
|
|
objects. <xref linkend="datatype-geo-table"> shows the geometric |
|
|
|
objects. <xref linkend="datatype-geo-table"> shows the geometric |
|
|
|
types available in PostgreSQL. The most fundamental type, the |
|
|
|
types available in <productname>PostgreSQL</productname>. The |
|
|
|
point, forms the basis for all of the other types. |
|
|
|
most fundamental type, the point, forms the basis for all of the |
|
|
|
|
|
|
|
other types. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<table id="datatype-geo-table"> |
|
|
|
<table id="datatype-geo-table"> |
|
|
|
@ -2746,9 +2758,10 @@ SELECT * FROM test1 WHERE a; |
|
|
|
|
|
|
|
|
|
|
|
<note> |
|
|
|
<note> |
|
|
|
<para> |
|
|
|
<para> |
|
|
|
Prior to <productname>PostgreSQL</> 7.2, <type>BIT</type> data was |
|
|
|
Prior to <productname>PostgreSQL</> 7.2, <type>BIT</type> data |
|
|
|
always silently truncated or zero-padded on the right, with or without an |
|
|
|
was always silently truncated or zero-padded on the right, with |
|
|
|
explicit cast. This was changed to comply with the SQL standard. |
|
|
|
or without an explicit cast. This was changed to comply with the |
|
|
|
|
|
|
|
<acronym>SQL</acronym> standard. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
</note> |
|
|
|
</note> |
|
|
|
|
|
|
|
|
|
|
|
@ -2978,14 +2991,14 @@ SELECT * FROM test; |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
A third identifier type used by the system is <type>cid</>, or command |
|
|
|
A third identifier type used by the system is <type>cid</>, or |
|
|
|
identifier. This is the data type of the system columns |
|
|
|
command identifier. This is the data type of the system columns |
|
|
|
<structfield>cmin</> and <structfield>cmax</>. |
|
|
|
<structfield>cmin</> and <structfield>cmax</>. Command |
|
|
|
Command identifiers are also 32-bit quantities. This creates a hard |
|
|
|
identifiers are also 32-bit quantities. This creates a hard limit |
|
|
|
limit of 2<superscript>32</> (4 billion) SQL commands within a single |
|
|
|
of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands |
|
|
|
transaction. |
|
|
|
within a single transaction. In practice this limit is not a |
|
|
|
In practice this limit is not a problem --- note that the limit is on |
|
|
|
problem --- note that the limit is on number of |
|
|
|
number of SQL commands, not number of tuples processed. |
|
|
|
<acronym>SQL</acronym> commands, not number of tuples processed. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
@ -3044,9 +3057,10 @@ SELECT * FROM test; |
|
|
|
column data type, but it can be used to declare a function's |
|
|
|
column data type, but it can be used to declare a function's |
|
|
|
argument or result type. Each of the available pseudo-types is |
|
|
|
argument or result type. Each of the available pseudo-types is |
|
|
|
useful in situations where a function's behavior does not |
|
|
|
useful in situations where a function's behavior does not |
|
|
|
correspond to simply taking or returning a value of a specific SQL |
|
|
|
correspond to simply taking or returning a value of a specific |
|
|
|
data type. <xref linkend="datatype-pseudotypes-table"> lists the |
|
|
|
<acronym>SQL</acronym> data type. <xref |
|
|
|
existing pseudo-types. |
|
|
|
linkend="datatype-pseudotypes-table"> lists the existing |
|
|
|
|
|
|
|
pseudo-types. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<table id="datatype-pseudotypes-table"> |
|
|
|
<table id="datatype-pseudotypes-table"> |
|
|
|
@ -3126,14 +3140,15 @@ SELECT * FROM test; |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
<para> |
|
|
|
The <type>internal</> pseudo-type is used to declare functions that are |
|
|
|
The <type>internal</> pseudo-type is used to declare functions |
|
|
|
meant only to be called internally by the database system, and not by |
|
|
|
that are meant only to be called internally by the database |
|
|
|
direct invocation in a SQL query. If a function has at least one |
|
|
|
system, and not by direct invocation in a <acronym>SQL</acronym> |
|
|
|
<type>internal</>-type argument then it cannot be called from SQL. |
|
|
|
query. If a function has at least one <type>internal</>-type |
|
|
|
To preserve the type safety of this restriction it is important to |
|
|
|
argument then it cannot be called from <acronym>SQL</acronym>. To |
|
|
|
follow this coding rule: do not create any function that is declared |
|
|
|
preserve the type safety of this restriction it is important to |
|
|
|
to return <type>internal</> unless it has at least one <type>internal</> |
|
|
|
follow this coding rule: do not create any function that is |
|
|
|
argument. |
|
|
|
declared to return <type>internal</> unless it has at least one |
|
|
|
|
|
|
|
<type>internal</> argument. |
|
|
|
</para> |
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
|
|
</sect1> |
|
|
|
</sect1> |
|
|
|
|
Bruce Momjian
23 years ago