2000-03-31 05:27:42 +02:00
|
|
|
<!--
|
2000-12-14 23:30:56 +01:00
|
|
|
$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.44 2000/12/14 22:30:56 petere Exp $
|
2000-03-31 05:27:42 +02:00
|
|
|
-->
|
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<chapter id="datatype">
|
1999-06-14 09:36:12 +02:00
|
|
|
<title id="datatype-title">Data Types</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<abstract>
|
|
|
|
<para>
|
|
|
|
Describes the built-in data types available in
|
|
|
|
<productname>Postgres</productname>.
|
|
|
|
</para>
|
|
|
|
</abstract>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
<productname>Postgres</productname> has a rich set of native data
|
|
|
|
types available to users.
|
|
|
|
Users may add new types to <productname>Postgres</productname> using the
|
2000-04-13 23:44:25 +02:00
|
|
|
<command>CREATE TYPE</command> command.
|
1999-05-12 09:32:47 +02:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
In the context of data types, the following sections will discuss
|
|
|
|
<acronym>SQL</acronym> standards compliance, porting issues, and usage.
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
Some <productname>Postgres</productname> types correspond directly to
|
|
|
|
<acronym>SQL92</acronym>-compatible types. In other
|
|
|
|
cases, data types defined by <acronym>SQL92</acronym> syntax are mapped directly
|
|
|
|
into native <productname>Postgres</productname> types.
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
Many of the built-in types have obvious external formats. However, several
|
|
|
|
types are either unique to <productname>Postgres</productname>,
|
|
|
|
such as open and closed paths, or have
|
|
|
|
several possibilities for formats, such as the date and time types.
|
|
|
|
</para>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Data Types</title>
|
|
|
|
<titleabbrev>Data Types</titleabbrev>
|
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry><productname>Postgres</productname> Type</entry>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry><acronym>SQL92</acronym> or <acronym>SQL99</acronym> Type</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>bool</entry>
|
|
|
|
<entry>boolean</entry>
|
|
|
|
<entry>logical boolean (true/false)</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>box</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>rectangular box in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>char(n)</entry>
|
|
|
|
<entry>character(n)</entry>
|
|
|
|
<entry>fixed-length character string</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>cidr</entry>
|
|
|
|
<entry></entry>
|
2000-11-10 21:13:27 +01:00
|
|
|
<entry>IP network address</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>circle</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>circle in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>date</entry>
|
|
|
|
<entry>date</entry>
|
|
|
|
<entry>calendar date without time of day</entry>
|
|
|
|
</row>
|
1999-10-13 04:44:23 +02:00
|
|
|
<row>
|
|
|
|
<entry>decimal</entry>
|
|
|
|
<entry>decimal(p,s)</entry>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry>exact numeric with selectable precision</entry>
|
1999-10-13 04:44:23 +02:00
|
|
|
</row>
|
1999-05-12 09:32:47 +02:00
|
|
|
<row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>float4</entry>
|
|
|
|
<entry>float(<replaceable>p</replaceable>), <replaceable>p</replaceable> < 7</entry>
|
|
|
|
<entry>floating-point number with precision <replaceable>p</replaceable></entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>float8</entry>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>float(<replaceable>p</replaceable>), 7 <= <replaceable>p</replaceable> < 16</entry>
|
|
|
|
<entry>floating-point number with precision <replaceable>p</replaceable></entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>inet</entry>
|
|
|
|
<entry></entry>
|
2000-11-10 21:13:27 +01:00
|
|
|
<entry>IP network or host address</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int2</entry>
|
|
|
|
<entry>smallint</entry>
|
|
|
|
<entry>signed two-byte integer</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int4</entry>
|
|
|
|
<entry>int, integer</entry>
|
|
|
|
<entry>signed 4-byte integer</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int8</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>signed 8-byte integer</entry>
|
|
|
|
</row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<row>
|
|
|
|
<entry>interval</entry>
|
|
|
|
<entry>interval</entry>
|
|
|
|
<entry>general-use time span</entry>
|
|
|
|
</row>
|
1999-05-12 09:32:47 +02:00
|
|
|
<row>
|
|
|
|
<entry>line</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>infinite line in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>lseg</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>line segment in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>money</entry>
|
|
|
|
<entry>decimal(9,2)</entry>
|
|
|
|
<entry>US-style currency</entry>
|
|
|
|
</row>
|
1999-10-13 04:44:23 +02:00
|
|
|
<row>
|
|
|
|
<entry>numeric</entry>
|
|
|
|
<entry>numeric(p,s)</entry>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry>exact numeric with selectable precision</entry>
|
1999-10-13 04:44:23 +02:00
|
|
|
</row>
|
1999-05-12 09:32:47 +02:00
|
|
|
<row>
|
|
|
|
<entry>path</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>open and closed geometric path in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>point</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>geometric point in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>polygon</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>closed geometric path in 2D plane</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>serial</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>unique id for indexing and cross-reference</entry>
|
|
|
|
</row>
|
2000-08-25 01:36:29 +02:00
|
|
|
<row>
|
|
|
|
<entry>text</entry>
|
|
|
|
<entry></entry>
|
|
|
|
<entry>variable-length character string</entry>
|
|
|
|
</row>
|
1999-05-12 09:32:47 +02:00
|
|
|
<row>
|
|
|
|
<entry>time</entry>
|
2000-07-14 17:26:21 +02:00
|
|
|
<entry>time [ without time zone ]</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
<entry>time of day</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>timetz</entry>
|
|
|
|
<entry>time with time zone</entry>
|
|
|
|
<entry>time of day, including time zone</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>timestamp</entry>
|
2000-07-14 17:26:21 +02:00
|
|
|
<entry>timestamp [ with time zone ]</entry>
|
1999-05-12 09:32:47 +02:00
|
|
|
<entry>date/time</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>varchar(n)</entry>
|
|
|
|
<entry>character varying(n)</entry>
|
|
|
|
<entry>variable-length character string</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
The <type>cidr</type> and <type>inet</type> types are designed to handle any IP type
|
|
|
|
but only ipv4 is handled in the current implementation.
|
2000-03-14 23:52:53 +01:00
|
|
|
Everything here that talks about ipv4 will apply to ipv6 in a
|
|
|
|
future release.
|
|
|
|
</para>
|
|
|
|
</note>
|
|
|
|
</para>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Function Constants</title>
|
|
|
|
<titleabbrev>Constants</titleabbrev>
|
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry><productname>Postgres</productname> Function</entry>
|
|
|
|
<entry><acronym>SQL92</acronym> Constant</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>date('now')</entry>
|
|
|
|
<entry>current_date</entry>
|
|
|
|
<entry>date of current transaction</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>time('now')</entry>
|
|
|
|
<entry>current_time</entry>
|
|
|
|
<entry>time of current transaction</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>timestamp('now')</entry>
|
|
|
|
<entry>current_timestamp</entry>
|
|
|
|
<entry>date and time of current transaction</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
1998-10-27 07:14:41 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
<productname>Postgres</productname> has features at the forefront of
|
|
|
|
<acronym>ORDBMS</acronym> development. In addition to
|
2000-08-25 01:36:29 +02:00
|
|
|
<acronym>SQL99</acronym> conformance, substantial portions
|
1999-05-12 09:32:47 +02:00
|
|
|
of <acronym>SQL92</acronym> are also supported.
|
|
|
|
Although we strive for <acronym>SQL92</acronym> compliance,
|
|
|
|
there are some aspects of the standard
|
|
|
|
which are ill considered and which should not live through subsequent standards.
|
|
|
|
<productname>Postgres</productname> will not make great efforts to
|
|
|
|
conform to these features; however, these tend to apply in little-used
|
2000-03-14 23:52:53 +01:00
|
|
|
or obsure cases, and a typical user is not likely to run into them.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
|
|
|
Most of the input and output functions corresponding to the
|
|
|
|
base types (e.g., integers and floating point numbers) do some
|
|
|
|
error-checking.
|
|
|
|
Some of the operators and functions (e.g.,
|
|
|
|
addition and multiplication) do not perform run-time error-checking in the
|
|
|
|
interests of improving execution speed.
|
|
|
|
On some systems, for example, the numeric operators for some data types may
|
|
|
|
silently underflow or overflow.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
2000-03-14 23:52:53 +01:00
|
|
|
Some of the input and output functions are not invertible. That is,
|
1999-05-12 09:32:47 +02:00
|
|
|
the result of an output function may lose precision when compared to
|
|
|
|
the original input.
|
1998-07-08 15:53:15 +02:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<note>
|
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
Floating point numbers are allowed to retain
|
1999-05-12 09:32:47 +02:00
|
|
|
most of the intrinsic precision of the type (typically 15 digits for doubles,
|
|
|
|
6 digits for 4-byte floats).
|
|
|
|
Other types with underlying floating point fields (e.g. geometric
|
2000-03-14 23:52:53 +01:00
|
|
|
types) carry similar precision.
|
|
|
|
</para>
|
1999-05-12 09:32:47 +02:00
|
|
|
</note>
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="numeric-types">
|
1999-05-12 09:32:47 +02:00
|
|
|
<title>Numeric Types</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-05-12 09:32:47 +02:00
|
|
|
<para>
|
2000-08-25 01:36:29 +02:00
|
|
|
Numeric types consist of two-, four-, and eight-byte integers,
|
|
|
|
four- and eight-byte
|
2000-05-02 22:02:03 +02:00
|
|
|
floating point numbers and fixed-precision decimals.
|
1998-12-18 17:11:12 +01:00
|
|
|
</para>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Numeric Types</title>
|
|
|
|
<titleabbrev>Numerics</titleabbrev>
|
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Numeric Type</entry>
|
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
<entry>Range</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
1999-10-13 04:44:23 +02:00
|
|
|
<row>
|
|
|
|
<entry>decimal</entry>
|
|
|
|
<entry>variable</entry>
|
|
|
|
<entry>User-specified precision</entry>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry>no limit</entry>
|
1999-10-13 04:44:23 +02:00
|
|
|
</row>
|
1999-08-06 15:43:42 +02:00
|
|
|
<row>
|
|
|
|
<entry>float4</entry>
|
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>Variable-precision</entry>
|
|
|
|
<entry>6 decimal places</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>float8</entry>
|
|
|
|
<entry>8 bytes</entry>
|
|
|
|
<entry>Variable-precision</entry>
|
|
|
|
<entry>15 decimal places</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int2</entry>
|
|
|
|
<entry>2 bytes</entry>
|
|
|
|
<entry>Fixed-precision</entry>
|
|
|
|
<entry>-32768 to +32767</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int4</entry>
|
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>Usual choice for fixed-precision</entry>
|
|
|
|
<entry>-2147483648 to +2147483647</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>int8</entry>
|
|
|
|
<entry>8 bytes</entry>
|
|
|
|
<entry>Very large range fixed-precision</entry>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry>~18 decimal places</entry>
|
1999-10-13 04:44:23 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>numeric</entry>
|
|
|
|
<entry>variable</entry>
|
|
|
|
<entry>User-specified precision</entry>
|
|
|
|
<entry>no limit</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>serial</entry>
|
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>Identifer or cross-reference</entry>
|
|
|
|
<entry>0 to +2147483647</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
The numeric types have a full set of corresponding arithmetic operators and
|
2000-12-14 23:30:56 +01:00
|
|
|
functions. Refer to <xref linkend="functions"> for more information.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <type>int8</type> type may not be available on all platforms since
|
2000-08-25 01:36:29 +02:00
|
|
|
it relies on compiler support for eight-byte integers.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>The Serial Type</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <type>serial</type> type is a special-case type constructed by
|
|
|
|
<productname>Postgres</productname> from other existing components.
|
|
|
|
It is typically used to create unique identifiers for table entries.
|
|
|
|
In the current implementation, specifying
|
|
|
|
|
|
|
|
<programlisting>
|
1998-10-14 18:26:31 +02:00
|
|
|
CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceable class="parameter">colname</replaceable> SERIAL);
|
1999-08-06 15:43:42 +02:00
|
|
|
</programlisting>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
is equivalent to specifying:
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<programlisting>
|
1998-10-14 18:26:31 +02:00
|
|
|
CREATE SEQUENCE <replaceable class="parameter">tablename</replaceable>_<replaceable class="parameter">colname</replaceable>_seq;
|
|
|
|
CREATE TABLE <replaceable class="parameter">tablename</replaceable>
|
|
|
|
(<replaceable class="parameter">colname</replaceable> INT4 DEFAULT nextval('<replaceable class="parameter">tablename</replaceable>_<replaceable class="parameter">colname</replaceable>_seq');
|
|
|
|
CREATE UNIQUE INDEX <replaceable class="parameter">tablename</replaceable>_<replaceable class="parameter">colname</replaceable>_key on <replaceable class="parameter">tablename</replaceable> (<replaceable class="parameter">colname</replaceable>);
|
1999-08-06 15:43:42 +02:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
<caution>
|
|
|
|
<para>
|
|
|
|
The implicit sequence created for the <type>serial</type> type will
|
|
|
|
<emphasis>not</emphasis> be automatically removed when the
|
|
|
|
table is dropped.
|
|
|
|
</para>
|
|
|
|
</caution>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
Implicit sequences supporting the <type>serial</type> are
|
|
|
|
not automatically dropped when a table containing a serial type
|
|
|
|
is dropped. So, the following commands executed in order will likely fail:
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<programlisting>
|
1998-10-14 18:26:31 +02:00
|
|
|
CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceable class="parameter">colname</replaceable> SERIAL);
|
|
|
|
DROP TABLE <replaceable class="parameter">tablename</replaceable>;
|
|
|
|
CREATE TABLE <replaceable class="parameter">tablename</replaceable> (<replaceable class="parameter">colname</replaceable> SERIAL);
|
1999-08-06 15:43:42 +02:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
The sequence will remain in the database until explicitly dropped using
|
|
|
|
<command>DROP SEQUENCE</command>.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="monetary-types">
|
1999-08-06 15:43:42 +02:00
|
|
|
<title>Monetary Type</title>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
<title>Obsolete Type</title>
|
|
|
|
<para>
|
2000-03-14 23:52:53 +01:00
|
|
|
The <type>money</type> is now deprecated. Use <type>numeric</type>
|
|
|
|
or <type>decimal</type> instead. The money type may become a
|
|
|
|
locale-aware layer over the numeric type in a future release.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
</note>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <type>money</type> type supports US-style currency with
|
|
|
|
fixed decimal point representation.
|
|
|
|
If <productname>Postgres</productname> is compiled with USE_LOCALE
|
|
|
|
then the money type should use the monetary conventions defined for
|
|
|
|
<citetitle>locale(7)</citetitle>.
|
1998-12-18 17:11:12 +01:00
|
|
|
</para>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
1999-05-27 17:47:28 +02:00
|
|
|
<para>
|
1999-08-06 15:43:42 +02:00
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Monetary Types</title>
|
|
|
|
<titleabbrev>Money</titleabbrev>
|
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Monetary Type</entry>
|
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
<entry>Range</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>money</entry>
|
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>Fixed-precision</entry>
|
|
|
|
<entry>-21474836.48 to +21474836.47</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
1999-05-27 17:47:28 +02:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<type>numeric</type>
|
|
|
|
will replace the money type, and should be preferred.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
</sect1>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="character-types">
|
1999-08-06 15:43:42 +02:00
|
|
|
<title>Character Types</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<acronym>SQL92</acronym> defines two primary character types:
|
|
|
|
<type>char</type> and <type>varchar</type>.
|
|
|
|
<productname>Postgres</productname> supports these types, in
|
|
|
|
addition to the more general <type>text</type> type,
|
|
|
|
which unlike <type>varchar</type>
|
2000-03-14 23:52:53 +01:00
|
|
|
does not require an explicit declared upper
|
|
|
|
limit on the size of the field.
|
1998-12-18 17:11:12 +01:00
|
|
|
</para>
|
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Character Types</title>
|
|
|
|
<titleabbrev>Characters</titleabbrev>
|
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Character Type</entry>
|
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Recommendation</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
2000-08-25 01:36:29 +02:00
|
|
|
<entry>"char"</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
<entry>1 byte</entry>
|
|
|
|
<entry><acronym>SQL92</acronym>-compatible</entry>
|
|
|
|
<entry>Single character</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>char(n)</entry>
|
|
|
|
<entry>(4+n) bytes</entry>
|
|
|
|
<entry><acronym>SQL92</acronym>-compatible</entry>
|
|
|
|
<entry>Fixed-length blank padded</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>text</entry>
|
2000-12-03 15:47:18 +01:00
|
|
|
<entry>(4+n) bytes</entry>
|
|
|
|
<entry>Most flexible</entry>
|
|
|
|
<entry>Variable unlimited length</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>varchar(n)</entry>
|
2000-11-16 07:03:40 +01:00
|
|
|
<entry>(4+n) bytes</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
<entry><acronym>SQL92</acronym>-compatible</entry>
|
|
|
|
<entry>Variable-length with limit</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-05-27 17:47:28 +02:00
|
|
|
<para>
|
2000-12-03 15:47:18 +01:00
|
|
|
There is one other fixed-length character type in <productname>Postgres</productname>.
|
|
|
|
The <type>name</type> type exists <emphasis>only</emphasis> for
|
|
|
|
storage of internal catalog names and
|
|
|
|
is not intended for use by the general user.
|
2000-03-14 23:52:53 +01:00
|
|
|
Its length is currently defined as 32 bytes (31 characters plus terminator)
|
1999-08-06 15:43:42 +02:00
|
|
|
but should be reference using NAMEDATALEN.
|
2000-03-14 23:52:53 +01:00
|
|
|
The length is set at compile time (and is therefore adjustable for
|
|
|
|
special uses); the default maximum length may change in a future release.
|
1999-05-27 17:47:28 +02:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Specialty Character Type</title>
|
|
|
|
<titleabbrev>Specialty Characters</titleabbrev>
|
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Character Type</entry>
|
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>name</entry>
|
|
|
|
<entry>32 bytes</entry>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>Thirty-one character internal type</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
</sect1>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="datetime-types">
|
1999-05-04 04:22:13 +02:00
|
|
|
<title>Date/Time Types</title>
|
|
|
|
|
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
<productname>Postgres</productname> supports the full set of
|
2000-01-23 02:27:39 +01:00
|
|
|
<acronym>SQL</acronym> date and time types.
|
1999-05-04 04:22:13 +02:00
|
|
|
</para>
|
1998-10-27 07:14:41 +01:00
|
|
|
|
1999-05-04 04:22:13 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Date/Time Types</title>
|
1999-05-04 04:22:13 +02:00
|
|
|
<titleabbrev>Date/Time</titleabbrev>
|
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>Type</entry>
|
|
|
|
<entry>Description</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
<entry>Storage</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>Earliest</entry>
|
|
|
|
<entry>Latest</entry>
|
|
|
|
<entry>Resolution</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry><type>timestamp</type></entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>both date and time</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>8 bytes</entry>
|
|
|
|
<entry>4713 BC</entry>
|
|
|
|
<entry>AD 1465001</entry>
|
|
|
|
<entry>1 microsec / 14 digits</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
</row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<row>
|
2000-07-14 17:26:21 +02:00
|
|
|
<entry><type>timestamp [ with time zone ]</type></entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>date and time with time zone</entry>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>8 bytes</entry>
|
|
|
|
<entry>1903 AD</entry>
|
|
|
|
<entry>2037 AD</entry>
|
|
|
|
<entry>1 microsec / 14 digits</entry>
|
|
|
|
</row>
|
1999-05-04 04:22:13 +02:00
|
|
|
<row>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry><type>interval</type></entry>
|
|
|
|
<entry>for time intervals</entry>
|
|
|
|
<entry>12 bytes</entry>
|
|
|
|
<entry>-178000000 years</entry>
|
|
|
|
<entry>178000000 years</entry>
|
2000-08-23 07:59:11 +02:00
|
|
|
<entry>1 microsecond</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry><type>date</type></entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>dates only</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>4713 BC</entry>
|
|
|
|
<entry>32767 AD</entry>
|
|
|
|
<entry>1 day</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
</row>
|
|
|
|
<row>
|
2000-07-14 17:26:21 +02:00
|
|
|
<entry><type>time [ without time zone ]</type></entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>times of day only</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>00:00:00.00</entry>
|
|
|
|
<entry>23:59:59.99</entry>
|
|
|
|
<entry>1 microsecond</entry>
|
1999-05-04 04:22:13 +02:00
|
|
|
</row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<row>
|
|
|
|
<entry><type>time with time zone</type></entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>times of day only</entry>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>4 bytes</entry>
|
|
|
|
<entry>00:00:00.00+12</entry>
|
|
|
|
<entry>23:59:59.99-12</entry>
|
|
|
|
<entry>1 microsecond</entry>
|
|
|
|
</row>
|
1999-05-04 04:22:13 +02:00
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<note>
|
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
To ensure compatibility to earlier versions of <productname>Postgres</productname>
|
2000-01-23 02:27:39 +01:00
|
|
|
we also continue to provide <type>datetime</type> (equivalent to <type>timestamp</type>) and
|
2000-05-02 22:02:03 +02:00
|
|
|
<type>timespan</type> (equivalent to <type>interval</type>),
|
|
|
|
however support for these is now restricted to having an
|
|
|
|
implicit translation to <type>timestamp</type> and
|
|
|
|
<type>interval</type>.
|
|
|
|
The types <type>abstime</type>
|
2000-01-23 02:27:39 +01:00
|
|
|
and <type>reltime</type> are lower precision types which are used internally.
|
2000-03-14 23:52:53 +01:00
|
|
|
You are discouraged from using any of these types in new
|
|
|
|
applications and are encouraged to move any old
|
2000-05-02 22:02:03 +02:00
|
|
|
ones over when appropriate. Any or all of these internal types might disappear in a future release.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</note>
|
1999-05-04 04:22:13 +02:00
|
|
|
</para>
|
1998-10-27 07:14:41 +01:00
|
|
|
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-01-19 17:08:26 +01:00
|
|
|
<sect2>
|
|
|
|
<title>Date/Time Input</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-01-19 17:08:26 +01:00
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
Date and time input is accepted in almost any reasonable format, including
|
2000-03-14 23:52:53 +01:00
|
|
|
<acronym>ISO-8601</acronym>, <acronym>SQL</acronym>-compatible,
|
2000-01-23 02:27:39 +01:00
|
|
|
traditional <productname>Postgres</productname>, and others.
|
|
|
|
The ordering of month and day in date input can be ambiguous, therefore a setting
|
2000-05-02 22:02:03 +02:00
|
|
|
exists to specify how it should be interpreted in ambiguous cases. The command
|
2000-01-23 02:27:39 +01:00
|
|
|
<literal>SET DateStyle TO 'US'</literal> or <literal>SET DateStyle TO 'NonEuropean'</literal>
|
2000-05-02 22:02:03 +02:00
|
|
|
specifies the variant "month before day", the command
|
2000-01-23 02:27:39 +01:00
|
|
|
<literal>SET DateStyle TO 'European'</literal> sets the variant
|
2000-05-02 22:02:03 +02:00
|
|
|
"day before month". The <literal>ISO</literal> style
|
2000-03-14 23:52:53 +01:00
|
|
|
is the default but this default can be changed at compile time or at run time.
|
1998-12-18 17:11:12 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-03-14 23:52:53 +01:00
|
|
|
See <xref endterm="datetime-appendix-title" linkend="datetime-appendix-title">
|
2000-01-23 02:27:39 +01:00
|
|
|
for the exact parsing rules of date/time input and for the recognized time zones.
|
1999-01-19 17:08:26 +01:00
|
|
|
</para>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-01-19 17:08:26 +01:00
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
Remember that any date or time input needs to be enclosed into single quotes,
|
|
|
|
like text strings.
|
1999-01-19 17:08:26 +01:00
|
|
|
</para>
|
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<sect3>
|
|
|
|
<title>date</title>
|
1999-01-19 17:08:26 +01:00
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
The following are possible inputs for the <type>date</type> type.
|
2000-03-14 23:52:53 +01:00
|
|
|
|
1999-01-19 17:08:26 +01:00
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Date Input</title>
|
1999-01-19 17:08:26 +01:00
|
|
|
<titleabbrev>Date Inputs</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Example</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>January 8, 1999</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>Unambiguous</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>1999-01-08</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>ISO-8601 format, preferred</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>1/8/1999</entry>
|
|
|
|
<entry>US; read as August 1 in European mode</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>8/1/1999</entry>
|
|
|
|
<entry>European; read as August 1 in US mode</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>1/18/1999</entry>
|
|
|
|
<entry>US; read as January 18 in any mode</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>19990108</entry>
|
|
|
|
<entry>ISO-8601 year, month, day</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>990108</entry>
|
|
|
|
<entry>ISO-8601 year, month, day</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>1999.008</entry>
|
|
|
|
<entry>Year and day of year</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>99008</entry>
|
|
|
|
<entry>Year and day of year</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>January 8, 99 BC</entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>Year 99 before the Common Era</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Month Abbreviations</title>
|
1999-01-19 17:08:26 +01:00
|
|
|
<titleabbrev>Month Abbreviations</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Month</entry>
|
|
|
|
<entry>Abbreviations</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>April</entry>
|
|
|
|
<entry>Apr</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>August</entry>
|
|
|
|
<entry>Aug</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>December</entry>
|
|
|
|
<entry>Dec</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>February</entry>
|
|
|
|
<entry>Feb</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>January</entry>
|
|
|
|
<entry>Jan</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>July</entry>
|
|
|
|
<entry>Jul</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>June</entry>
|
|
|
|
<entry>Jun</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>March</entry>
|
|
|
|
<entry>Mar</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>November</entry>
|
|
|
|
<entry>Nov</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>October</entry>
|
|
|
|
<entry>Oct</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>September</entry>
|
|
|
|
<entry>Sep, Sept</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
The month <literal>May</literal> has no explicit abbreviation, for obvious reasons.
|
|
|
|
</para>
|
|
|
|
</note>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Day of Week Abbreviations</title>
|
1999-01-19 17:08:26 +01:00
|
|
|
<titleabbrev>Day of Week Abbreviations</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Day</entry>
|
|
|
|
<entry>Abbreviation</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>Sunday</entry>
|
|
|
|
<entry>Sun</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Monday</entry>
|
|
|
|
<entry>Mon</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Tuesday</entry>
|
|
|
|
<entry>Tue, Tues</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Wednesday</entry>
|
|
|
|
<entry>Wed, Weds</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Thursday</entry>
|
|
|
|
<entry>Thu, Thur, Thurs</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Friday</entry>
|
|
|
|
<entry>Fri</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>Saturday</entry>
|
|
|
|
<entry>Sat</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
</sect3>
|
1999-01-19 17:08:26 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<sect3>
|
2000-07-14 17:26:21 +02:00
|
|
|
<title>time [ without time zone ]</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Per SQL99, this type can be referenced as <type>time</type> and
|
|
|
|
as <type>time without time zone</type>.
|
|
|
|
</para>
|
|
|
|
|
2000-03-14 23:52:53 +01:00
|
|
|
<para>
|
|
|
|
The following are valid <type>time</type> inputs.
|
|
|
|
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Time Input</title>
|
2000-03-14 23:52:53 +01:00
|
|
|
<titleabbrev>Time Inputs</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Example</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>04:05:06.789</entry>
|
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>04:05:06</entry>
|
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>04:05</entry>
|
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>040506</entry>
|
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>04:05 AM</entry>
|
|
|
|
<entry>Same as 04:05; AM does not affect value</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>04:05 PM</entry>
|
|
|
|
<entry>Same as 16:05; input hour must be <= 12</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>z</entry>
|
|
|
|
<entry>Same as 00:00:00</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>zulu</entry>
|
|
|
|
<entry>Same as 00:00:00</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>allballs</entry>
|
|
|
|
<entry>Same as 00:00:00</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
</sect3>
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
<title>time with time zone</title>
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2000-03-14 23:52:53 +01:00
|
|
|
<para>
|
|
|
|
This type is defined by SQL92, but the definition exhibits
|
2000-05-02 22:02:03 +02:00
|
|
|
fundamental deficiencies which renders the type nearly useless. In
|
2000-03-14 23:52:53 +01:00
|
|
|
most cases, a combination of <type>date</type>,
|
2000-05-02 22:02:03 +02:00
|
|
|
<type>time</type>, and <type>timestamp</type>
|
2000-03-14 23:52:53 +01:00
|
|
|
should provide a complete range of date/time functionality
|
2000-05-02 22:02:03 +02:00
|
|
|
required by any application.
|
2000-03-14 23:52:53 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<type>time with time zone</type> accepts all input also legal
|
|
|
|
for the <type>time</type> type, appended with a legal time zone,
|
|
|
|
as follows:
|
|
|
|
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Time With Time
|
2000-03-14 23:52:53 +01:00
|
|
|
Zone Input</title>
|
|
|
|
<titleabbrev>Time With Time Zone Inputs</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
1999-01-19 17:08:26 +01:00
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Example</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>04:05:06.789-8</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>ISO-8601</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
</row>
|
|
|
|
<row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>04:05:06-08:00</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
2000-03-14 23:52:53 +01:00
|
|
|
<entry>04:05-08:00</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
2000-03-26 20:32:30 +02:00
|
|
|
<entry>040506-08</entry>
|
1999-01-19 17:08:26 +01:00
|
|
|
<entry>ISO-8601</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
2000-03-14 23:52:53 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Refer to <xref endterm="timezone-title" linkend="timezone"> for
|
|
|
|
more examples of time zones.
|
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
</sect3>
|
|
|
|
|
|
|
|
<sect3>
|
|
|
|
<title>timestamp</title>
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
Valid input for the <type>timestamp</type> type consists of a concatenation
|
|
|
|
of a date and a time, followed by an optional <literal>AD</literal> or
|
|
|
|
<literal>BC</literal>, followed by an optional time zone. (See below.)
|
|
|
|
Thus
|
|
|
|
|
|
|
|
<programlisting>
|
2000-01-23 02:27:39 +01:00
|
|
|
1999-01-08 04:05:06 -8:00
|
2000-05-02 22:02:03 +02:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
is a valid <type>timestamp</type> value, which is <acronym>ISO</acronym>-compliant.
|
|
|
|
In addition, the wide-spread format
|
|
|
|
|
|
|
|
<programlisting>
|
2000-01-23 02:27:39 +01:00
|
|
|
January 8 04:05:06 1999 PST
|
2000-05-02 22:02:03 +02:00
|
|
|
</programlisting>
|
|
|
|
is supported.
|
|
|
|
</para>
|
1999-01-19 17:08:26 +01:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<para>
|
|
|
|
<table tocentry="1" id="timezone">
|
|
|
|
<title id="timezone-title"><productname>Postgres</productname> Time Zone Input</title>
|
|
|
|
<titleabbrev>Time Zone Inputs</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Time Zone</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>PST</entry>
|
|
|
|
<entry>Pacific Standard Time</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>-8:00</entry>
|
|
|
|
<entry>ISO-8601 offset for PST</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>-800</entry>
|
|
|
|
<entry>ISO-8601 offset for PST</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>-8</entry>
|
|
|
|
<entry>ISO-8601 offset for PST</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
</sect3>
|
1999-01-19 17:08:26 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<sect3>
|
|
|
|
<title>interval</title>
|
2000-05-02 22:02:03 +02:00
|
|
|
|
1999-01-19 17:08:26 +01:00
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
<type>interval</type>s can be specified with the following syntax:
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
<programlisting>
|
2000-01-23 02:27:39 +01:00
|
|
|
Quantity Unit [Quantity Unit...] [Direction]
|
|
|
|
@ Quantity Unit [Direction]
|
2000-05-02 22:02:03 +02:00
|
|
|
</programlisting>
|
|
|
|
|
|
|
|
where: <literal>Quantity</literal> is ..., <literal>-1</literal>,
|
|
|
|
<literal>0</literal>, <literal>1</literal>, <literal>2</literal>, ...;
|
|
|
|
<literal>Unit</literal> is <literal>second</literal>,
|
|
|
|
<literal>minute</literal>, <literal>hour</literal>, <literal>day</literal>,
|
|
|
|
<literal>week</literal>, <literal>month</literal>, <literal>year</literal>,
|
|
|
|
<literal>decade</literal>, <literal>century</literal>, <literal>millennium</literal>,
|
|
|
|
or abbreviations or plurals of these units;
|
|
|
|
<literal>Direction</literal> can be <literal>ago</literal> or
|
|
|
|
empty.
|
|
|
|
</para>
|
|
|
|
</sect3>
|
1999-02-13 04:42:10 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<sect3>
|
2000-05-02 22:02:03 +02:00
|
|
|
<title>Special values</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The following <acronym>SQL</acronym>-compatible functions can be used as date or time
|
|
|
|
input for the corresponding datatype: <literal>CURRENT_DATE</literal>,
|
|
|
|
<literal>CURRENT_TIME</literal>, <literal>CURRENT_TIMESTAMP</literal>.
|
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
<productname>Postgres</productname> also supports several special constants for
|
|
|
|
convenience.
|
2000-01-23 02:27:39 +01:00
|
|
|
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Special Date/Time Constants</title>
|
2000-01-23 02:27:39 +01:00
|
|
|
<titleabbrev>Constants</titleabbrev>
|
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Constant</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>current</entry>
|
|
|
|
<entry>Current transaction time, deferred</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>epoch</entry>
|
|
|
|
<entry>1970-01-01 00:00:00+00 (Unix system time zero)</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>infinity</entry>
|
|
|
|
<entry>Later than other valid times</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>-infinity</entry>
|
|
|
|
<entry>Earlier than other valid times</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>invalid</entry>
|
|
|
|
<entry>Illegal entry</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>now</entry>
|
|
|
|
<entry>Current transaction time</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>today</entry>
|
|
|
|
<entry>Midnight today</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>tomorrow</entry>
|
|
|
|
<entry>Midnight tomorrow</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>yesterday</entry>
|
|
|
|
<entry>Midnight yesterday</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
<literal>'now'</literal> is resolved when the value is inserted, <literal>'current'</literal>
|
|
|
|
is resolved everytime the value is retrieved. So you probably want to use <literal>'now'</literal>
|
|
|
|
in most applications. (Of course you <emphasis>really</emphasis> want to use
|
|
|
|
<literal>CURRENT_TIMESTAMP</literal>, which is equivalent to <literal>'now'</literal>.)
|
1999-01-19 17:08:26 +01:00
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
</sect3>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-02-13 04:42:10 +01:00
|
|
|
</sect2>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
|
1999-02-13 04:42:10 +01:00
|
|
|
<sect2>
|
2000-01-23 02:27:39 +01:00
|
|
|
<title>Date/Time Output</title>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
Output formats can be set to one of the four styles
|
|
|
|
ISO-8601, <acronym>SQL</acronym> (Ingres), traditional
|
|
|
|
Postgres, and German, using the <command>SET DateStyle</command>.
|
|
|
|
The default is the <acronym>ISO</acronym> format.
|
|
|
|
|
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Date/Time Output Styles</title>
|
2000-01-23 02:27:39 +01:00
|
|
|
<titleabbrev>Styles</titleabbrev>
|
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Style Specification</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
<entry>Example</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>'ISO'</entry>
|
|
|
|
<entry>ISO-8601 standard</entry>
|
|
|
|
<entry>1997-12-17 07:37:16-08</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>'SQL'</entry>
|
|
|
|
<entry>Traditional style</entry>
|
|
|
|
<entry>12/17/1997 07:37:16.00 PST</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>'Postgres'</entry>
|
|
|
|
<entry>Original style</entry>
|
|
|
|
<entry>Wed Dec 17 07:37:16 1997 PST</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>'German'</entry>
|
|
|
|
<entry>Regional style</entry>
|
|
|
|
<entry>17.12.1997 07:37:16.00 PST</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
The output of the <type>date</type> and <type>time</type> styles is of course
|
2000-05-02 22:02:03 +02:00
|
|
|
only the date or time part in accordance with the above examples.
|
1998-12-18 17:11:12 +01:00
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
The <acronym>SQL</acronym> style has European and non-European (US) variants,
|
|
|
|
which determines whether month follows day or vica versa. (See also above
|
|
|
|
at Date/Time Input, how this setting affects interpretation of input values.)
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<table tocentry="1">
|
2000-05-02 22:02:03 +02:00
|
|
|
<title><productname>Postgres</productname> Date Order Conventions</title>
|
|
|
|
<titleabbrev>Date Order</titleabbrev>
|
2000-01-23 02:27:39 +01:00
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Style Specification</entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry>Description</entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>Example</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>European</entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry><replaceable>day</replaceable>/<replaceable>month</replaceable>/<replaceable>year</replaceable></entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>17/12/1997 15:37:16.00 MET</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>US</entry>
|
2000-05-02 22:02:03 +02:00
|
|
|
<entry><replaceable>month</replaceable>/<replaceable>day</replaceable>/<replaceable>year</replaceable></entry>
|
2000-01-23 02:27:39 +01:00
|
|
|
<entry>12/17/1997 07:37:16.00 PST</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
<type>interval</type> output looks like the input format, except that units like
|
2000-01-23 02:27:39 +01:00
|
|
|
<literal>week</literal> or <literal>century</literal> are converted to years and days.
|
|
|
|
In ISO mode the output looks like
|
2000-05-02 22:02:03 +02:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<programlisting>
|
|
|
|
[ Quantity Units [ ... ] ] [ Days ] Hours:Minutes [ ago ]
|
|
|
|
</programlisting>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
There are several ways to affect the appearance of date/time types:
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <envar>PGDATESTYLE</envar> environment variable used by the backend directly
|
2000-08-29 22:02:09 +02:00
|
|
|
on postmaster start-up.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <envar>PGDATESTYLE</envar> environment variable used by the frontend libpq
|
2000-08-29 22:02:09 +02:00
|
|
|
on session start-up.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
<command>SET DATESTYLE</command> <acronym>SQL</acronym> command.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
</sect2>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<sect2>
|
2000-01-23 02:27:39 +01:00
|
|
|
<title>Time Zones</title>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
<productname>Postgres</productname> endeavors to be compatible with
|
2000-01-23 02:27:39 +01:00
|
|
|
<acronym>SQL92</acronym> definitions for typical usage.
|
|
|
|
However, the <acronym>SQL92</acronym> standard has an odd mix of date and
|
|
|
|
time types and capabilities. Two obvious problems are:
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Although the <type>date</type> type
|
|
|
|
does not have an associated time zone, the
|
|
|
|
<type>time</type> type can or does.
|
2000-11-11 20:50:31 +01:00
|
|
|
Time zones in the real world can have no meaning unless
|
|
|
|
associated with a date as well as a time
|
|
|
|
since the offset may vary through the year with daylight savings
|
|
|
|
time boundaries.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The default time zone is specified as a constant integer offset
|
2000-11-11 20:50:31 +01:00
|
|
|
from GMT/UTC. It is not possible to adapt to daylight savings
|
|
|
|
time when doing date/time arithmetic across
|
|
|
|
<acronym>DST</acronym> boundaries.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
1998-10-14 18:26:31 +02:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
</itemizedlist>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<para>
|
2000-11-11 20:50:31 +01:00
|
|
|
To address these difficulties, we recommend using date/time
|
|
|
|
types which contain both date and time when using time zones. We
|
|
|
|
recommend <emphasis>not</emphasis> using the SQL92 type TIME
|
|
|
|
WITH TIME ZONE (though it is supported by
|
|
|
|
<productname>Postgres</productname> for legacy applications and
|
|
|
|
for compatibility with other RDBMS implementations).
|
|
|
|
<productname>Postgres</productname>
|
|
|
|
assumes local time for any type containing only
|
2000-01-23 02:27:39 +01:00
|
|
|
date or time. Further, time zone support is derived from
|
|
|
|
the underlying operating system
|
|
|
|
time zone capabilities, and hence can handle daylight savings time
|
|
|
|
and other expected behavior.
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
<productname>Postgres</productname> obtains time zone support
|
2000-01-23 02:27:39 +01:00
|
|
|
from the underlying operating system for dates between 1902 and
|
|
|
|
2038 (near the typical date limits for Unix-style
|
|
|
|
systems). Outside of this range, all dates are assumed to be
|
|
|
|
specified and used in Universal Coordinated Time (UTC).
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-11-11 20:50:31 +01:00
|
|
|
All dates and times are stored internally in UTC,
|
|
|
|
traditionally known as Greenwich Mean Time (GMT).
|
2000-01-23 02:27:39 +01:00
|
|
|
Times are converted to local time on the database server before being
|
|
|
|
sent to the client frontend, hence by default are in the server
|
|
|
|
time zone.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<para>
|
|
|
|
There are several ways to affect the time zone behavior:
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-01-23 02:27:39 +01:00
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2000-11-11 20:50:31 +01:00
|
|
|
The TZ environment variable is used by the backend directly
|
2000-08-29 22:02:09 +02:00
|
|
|
on postmaster start-up as the default time zone.
|
2000-01-23 02:27:39 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The PGTZ environment variable set at the client used by libpq
|
|
|
|
to send time zone information to the backend upon connection.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <acronym>SQL</acronym> command <command>SET TIME ZONE</command>
|
|
|
|
sets the time zone for the session.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
2000-11-11 20:50:31 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The <acronym>SQL92</acronym> qualifier on
|
|
|
|
<programlisting>
|
|
|
|
<replaceable>timestamp</replaceable> AT TIME ZONE '<replaceable>zone</replaceable>'
|
|
|
|
</programlisting>
|
|
|
|
where <replaceable>zone</replaceable> can be specified as a
|
|
|
|
text time zone (e.g. <literal>'PST'</literal>) or as an
|
|
|
|
interval (e.g. <literal>INTERVAL '-08:00'</literal>).
|
|
|
|
</para>
|
|
|
|
</listitem>
|
2000-01-23 02:27:39 +01:00
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-11-11 20:50:31 +01:00
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
If an invalid time zone is specified,
|
|
|
|
the time zone becomes GMT (on most systems anyway).
|
|
|
|
</para>
|
|
|
|
</note>
|
2000-01-23 02:27:39 +01:00
|
|
|
|
|
|
|
<note>
|
|
|
|
<para>
|
|
|
|
If the compiler option USE_AUSTRALIAN_RULES is set
|
|
|
|
then <literal>EST</literal> refers to Australia Eastern Std Time,
|
|
|
|
which has an offset of +10:00 hours from UTC.
|
|
|
|
</para>
|
|
|
|
</note>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
2000-01-23 02:27:39 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
2000-01-23 02:27:39 +01:00
|
|
|
<title>Internals</title>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-05-02 22:02:03 +02:00
|
|
|
<productname>Postgres</productname> uses Julian dates
|
2000-01-23 02:27:39 +01:00
|
|
|
for all date/time calculations. They have the nice property of correctly
|
|
|
|
predicting/calculating any date more recent than 4713BC
|
|
|
|
to far into the future, using the assumption that the length of the
|
|
|
|
year is 365.2425 days.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2000-01-23 02:27:39 +01:00
|
|
|
Date conventions before the 19th century make for interesting reading,
|
|
|
|
but are not consistant enough to warrant coding into a date/time handler.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="boolean-type">
|
1999-08-06 15:43:42 +02:00
|
|
|
<title>Boolean Type</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<productname>Postgres</productname> supports <type>bool</type> as
|
2000-08-25 01:36:29 +02:00
|
|
|
the <acronym>SQL99</acronym> boolean type.
|
1999-08-06 15:43:42 +02:00
|
|
|
<type>bool</type> can have one of only two states: 'true' or 'false'.
|
|
|
|
A third state, 'unknown', is not
|
2000-08-25 01:36:29 +02:00
|
|
|
implemented and is not suggested in <acronym>SQL99</acronym>;
|
1999-08-06 15:43:42 +02:00
|
|
|
<acronym>NULL</acronym> is an
|
|
|
|
effective substitute. <type>bool</type> can be used in any boolean expression,
|
|
|
|
and boolean expressions
|
|
|
|
always evaluate to a result compatible with this type.</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<type>bool</type> uses 1 byte of storage.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Boolean Type</title>
|
|
|
|
<titleabbrev>Booleans</titleabbrev>
|
|
|
|
<tgroup cols="3">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>State</entry>
|
|
|
|
<entry>Output</entry>
|
|
|
|
<entry>Input</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>True</entry>
|
|
|
|
<entry>'t'</entry>
|
|
|
|
<entry>TRUE, 't', 'true', 'y', 'yes', '1'</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>False</entry>
|
|
|
|
<entry>'f'</entry>
|
|
|
|
<entry>FALSE, 'f', 'false', 'n', 'no', '0'</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="geometric-types">
|
1999-08-06 15:43:42 +02:00
|
|
|
<title>Geometric Types</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Geometric types represent two-dimensional spatial objects.
|
|
|
|
The most fundamental type,
|
|
|
|
the point, forms the basis for all of the other types.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<table tocentry="1">
|
|
|
|
<title><productname>Postgres</productname> Geometric Types</title>
|
|
|
|
<titleabbrev>Geometrics</titleabbrev>
|
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>Geometric Type</entry>
|
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Representation</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
|
|
|
<row>
|
|
|
|
<entry>point</entry>
|
|
|
|
<entry>16 bytes</entry>
|
|
|
|
<entry>(x,y)</entry>
|
|
|
|
<entry>Point in space</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>line</entry>
|
|
|
|
<entry>32 bytes</entry>
|
|
|
|
<entry>((x1,y1),(x2,y2))</entry>
|
|
|
|
<entry>Infinite line</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>lseg</entry>
|
|
|
|
<entry>32 bytes</entry>
|
|
|
|
<entry>((x1,y1),(x2,y2))</entry>
|
|
|
|
<entry>Finite line segment</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>box</entry>
|
|
|
|
<entry>32 bytes</entry>
|
|
|
|
<entry>((x1,y1),(x2,y2))</entry>
|
|
|
|
<entry>Rectangular box</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>path</entry>
|
|
|
|
<entry>4+32n bytes</entry>
|
|
|
|
<entry>((x1,y1),...)</entry>
|
|
|
|
<entry>Closed path (similar to polygon)</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>path</entry>
|
|
|
|
<entry>4+32n bytes</entry>
|
|
|
|
<entry>[(x1,y1),...]</entry>
|
|
|
|
<entry>Open path</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>polygon</entry>
|
|
|
|
<entry>4+32n bytes</entry>
|
|
|
|
<entry>((x1,y1),...)</entry>
|
|
|
|
<entry>Polygon (similar to closed path)</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>circle</entry>
|
|
|
|
<entry>24 bytes</entry>
|
|
|
|
<entry><(x,y),r></entry>
|
|
|
|
<entry>Circle (center and radius)</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
A rich set of functions and operators is available to perform various geometric
|
|
|
|
operations such as scaling, translation, rotation, and determining
|
|
|
|
intersections.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Point</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1998-12-18 17:11:12 +01:00
|
|
|
<para>
|
|
|
|
Points are the fundamental two-dimensional building block for geometric types.
|
|
|
|
</para>
|
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<type>point</type> is specified using the following syntax:
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<synopsis>
|
|
|
|
( <replaceable>x</replaceable> , <replaceable>y</replaceable> )
|
|
|
|
<replaceable>x</replaceable> , <replaceable>y</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>x</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The x-axis coordinate as a floating point number.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>y</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The y-axis coordinate as a floating point number.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<sect2>
|
|
|
|
<title>Line Segment</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
Line segments (<type>lseg</type>) are represented by pairs of points.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<type>lseg</type> is specified using the following syntax:
|
2000-05-02 22:02:03 +02:00
|
|
|
|
|
|
|
<synopsis>
|
|
|
|
( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> ) )
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> )
|
|
|
|
<replaceable>x1</replaceable> , <replaceable>y1</replaceable> , <replaceable>x2</replaceable> , <replaceable>y2</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>(<replaceable>x1</replaceable>,<replaceable>y1</replaceable>)</term>
|
|
|
|
<term>(<replaceable>x2</replaceable>,<replaceable>y2</replaceable>)</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The endpoints of the line segment.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<sect2>
|
|
|
|
<title>Box</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
Boxes are represented by pairs of points which are opposite
|
|
|
|
corners of the box.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
1998-12-18 17:11:12 +01:00
|
|
|
<type>box</type> is specified using the following syntax:
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<synopsis>
|
|
|
|
( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> ) )
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ( <replaceable>x2</replaceable> , <replaceable>y2</replaceable> )
|
|
|
|
<replaceable>x1</replaceable> , <replaceable>y1</replaceable> , <replaceable>x2</replaceable> , <replaceable>y2</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>(<replaceable>x1</replaceable>,<replaceable>y1</replaceable>)</term>
|
|
|
|
<term>(<replaceable>x2</replaceable>,<replaceable>y2</replaceable>)</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Opposite corners of the box.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<para>
|
1999-08-06 15:43:42 +02:00
|
|
|
Boxes are output using the first syntax.
|
|
|
|
The corners are reordered on input to store
|
|
|
|
the lower left corner first and the upper right corner last.
|
|
|
|
Other corners of the box can be entered, but the lower
|
|
|
|
left and upper right corners are determined from the input and stored.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Path</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Paths are represented by connected sets of points. Paths can be "open", where
|
|
|
|
the first and last points in the set are not connected, and "closed",
|
|
|
|
where the first and last point are connected. Functions
|
|
|
|
<function>popen(p)</function>
|
|
|
|
and
|
|
|
|
<function>pclose(p)</function>
|
|
|
|
are supplied to force a path to be open or closed, and functions
|
|
|
|
<function>isopen(p)</function>
|
|
|
|
and
|
|
|
|
<function>isclosed(p)</function>
|
2000-05-02 22:02:03 +02:00
|
|
|
are supplied to test for either type in a query.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<type>path</type> is specified using the following syntax:
|
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<synopsis>
|
|
|
|
( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) )
|
|
|
|
[ ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) ]
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> , ... , <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
|
|
|
|
<replaceable>x1</replaceable> , <replaceable>y1</replaceable> , ... , <replaceable>xn</replaceable> , <replaceable>yn</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>(<replaceable>x</replaceable>,<replaceable>y</replaceable>)</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Endpoints of the line segments comprising the path.
|
|
|
|
A leading square bracket ("[") indicates an open path, while
|
|
|
|
a leading parenthesis ("(") indicates a closed path.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<para>
|
1999-08-06 15:43:42 +02:00
|
|
|
Paths are output using the first syntax.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
<sect2>
|
|
|
|
<title>Polygon</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Polygons are represented by sets of points. Polygons should probably be
|
|
|
|
considered equivalent to closed paths, but are stored differently
|
|
|
|
and have their own set of support routines.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<type>polygon</type> is specified using the following syntax:
|
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<synopsis>
|
|
|
|
( ( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> ) )
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> ) , ... , ( <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
|
|
|
|
( <replaceable>x1</replaceable> , <replaceable>y1</replaceable> , ... , <replaceable>xn</replaceable> , <replaceable>yn</replaceable> )
|
|
|
|
<replaceable>x1</replaceable> , <replaceable>y1</replaceable> , ... , <replaceable>xn</replaceable> , <replaceable>yn</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>(<replaceable>x</replaceable>,<replaceable>y</replaceable>)</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Endpoints of the line segments comprising the boundary of the
|
|
|
|
polygon.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<para>
|
1999-08-06 15:43:42 +02:00
|
|
|
Polygons are output using the first syntax.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<sect2>
|
|
|
|
<title>Circle</title>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
Circles are represented by a center point and a radius.
|
|
|
|
</para>
|
1998-03-01 09:16:16 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
|
|
|
<type>circle</type> is specified using the following syntax:
|
1998-03-01 09:16:16 +01:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<synopsis>
|
|
|
|
< ( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable> >
|
|
|
|
( ( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable> )
|
|
|
|
( <replaceable>x</replaceable> , <replaceable>y</replaceable> ) , <replaceable>r</replaceable>
|
|
|
|
<replaceable>x</replaceable> , <replaceable>y</replaceable> , <replaceable>r</replaceable>
|
|
|
|
</synopsis>
|
|
|
|
|
|
|
|
where the arguments are
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
|
|
<term>(<replaceable>x</replaceable>,<replaceable>y</replaceable>)</term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Center of the circle.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
<term><replaceable>r</replaceable></term>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Radius of the circle.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
|
|
</para>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-05-02 22:02:03 +02:00
|
|
|
<para>
|
1999-08-06 15:43:42 +02:00
|
|
|
Circles are output using the first syntax.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
|
|
</sect1>
|
|
|
|
|
2000-09-29 22:21:34 +02:00
|
|
|
<sect1 id="net-types">
|
2000-10-04 17:47:45 +02:00
|
|
|
<title>Network Address Data Types</title>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-10-04 17:47:45 +02:00
|
|
|
<productname>Postgres</> offers data types to store IP and MAC
|
2000-11-10 21:13:27 +01:00
|
|
|
addresses. It is preferable to use these types over plain text
|
2000-10-04 17:47:45 +02:00
|
|
|
types, because these types offer input error checking and several
|
|
|
|
specialized operators and functions.
|
1999-08-06 15:43:42 +02:00
|
|
|
|
2000-10-04 17:47:45 +02:00
|
|
|
<table tocentry="1" id="net-types-table">
|
|
|
|
<title>Network Address Data Types</title>
|
1999-08-06 15:43:42 +02:00
|
|
|
<tgroup cols="4">
|
|
|
|
<thead>
|
|
|
|
<row>
|
2000-10-04 17:47:45 +02:00
|
|
|
<entry>Name</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
<entry>Storage</entry>
|
|
|
|
<entry>Description</entry>
|
|
|
|
<entry>Range</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
2000-10-04 17:47:45 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<row>
|
|
|
|
<entry>cidr</entry>
|
2000-11-10 21:13:27 +01:00
|
|
|
<entry>12 bytes</entry>
|
2000-10-04 17:47:45 +02:00
|
|
|
<entry>IP networks</entry>
|
|
|
|
<entry>valid IPv4 networks</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
</row>
|
2000-10-04 17:47:45 +02:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<row>
|
|
|
|
<entry>inet</entry>
|
2000-11-10 21:13:27 +01:00
|
|
|
<entry>12 bytes</entry>
|
2000-10-04 17:47:45 +02:00
|
|
|
<entry>IP hosts and networks</entry>
|
2000-11-10 21:13:27 +01:00
|
|
|
<entry>valid IPv4 hosts or networks</entry>
|
1999-08-06 15:43:42 +02:00
|
|
|
</row>
|
2000-10-04 17:47:45 +02:00
|
|
|
|
|
|
|
<row>
|
|
|
|
<entry>macaddr</entry>
|
|
|
|
<entry>6 bytes</entry>
|
|
|
|
<entry>MAC addresses</entry>
|
|
|
|
<entry>customary formats</entry>
|
|
|
|
</row>
|
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
|
|
|
|
2000-10-04 17:47:45 +02:00
|
|
|
<para>
|
|
|
|
IP v6 is not supported, yet.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
2000-11-10 21:13:27 +01:00
|
|
|
<sect2 id="inet-type">
|
|
|
|
<title><type>inet</type></title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <type>inet</type> type holds an IP host address, and
|
|
|
|
optionally the identity of the subnet it is in, all in one field.
|
|
|
|
The subnet identity is represented by the number of bits in the
|
|
|
|
network part of the address (the "netmask"). If the netmask is 32,
|
|
|
|
then the value does not indicate a subnet, only a single host.
|
|
|
|
Note that if you want to accept networks only, you should use the
|
|
|
|
<type>cidr</type> type rather than <type>inet</type>.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The input format for this type is <replaceable
|
|
|
|
class="parameter">x.x.x.x/y</replaceable> where <replaceable
|
|
|
|
class="parameter">x.x.x.x</replaceable> is an IP address and
|
|
|
|
<replaceable class="parameter">y</replaceable> is the number of
|
|
|
|
bits in the netmask. If the <replaceable
|
|
|
|
class="parameter">y</replaceable> part is left off, then the
|
|
|
|
netmask is 32, and the value represents just a single host.
|
|
|
|
On display, the <replaceable class="parameter">/y</replaceable>
|
|
|
|
portion is suppressed if the netmask is 32.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
2000-10-04 17:47:45 +02:00
|
|
|
<sect2 id="cidr-type">
|
|
|
|
<title><type>cidr</></title>
|
1999-08-06 15:43:42 +02:00
|
|
|
|
|
|
|
<para>
|
2000-11-10 21:13:27 +01:00
|
|
|
The <type>cidr</type> type holds an IP network specification.
|
|
|
|
Input and output formats follow Classless Internet Domain Routing
|
|
|
|
conventions.
|
|
|
|
The format for
|
2000-10-04 17:47:45 +02:00
|
|
|
specifying classless networks is <replaceable
|
|
|
|
class="parameter">x.x.x.x/y</> where <replaceable
|
|
|
|
class="parameter">x.x.x.x</> is the network and <replaceable
|
|
|
|
class="parameter">y</> is the number of bits in the netmask. If
|
|
|
|
<replaceable class="parameter">y</> omitted, it is calculated
|
2000-11-10 21:13:27 +01:00
|
|
|
using assumptions from the older classful numbering system, except
|
|
|
|
that it will be at least large enough to include all of the octets
|
|
|
|
written in the input.
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Here are some examples:
|
1998-10-27 07:14:41 +01:00
|
|
|
|
1998-12-18 17:11:12 +01:00
|
|
|
<table tocentry="1">
|
2000-10-04 17:47:45 +02:00
|
|
|
<title><type>cidr</> Type Input Examples</title>
|
1998-12-18 17:11:12 +01:00
|
|
|
<tgroup cols="2">
|
|
|
|
<thead>
|
|
|
|
<row>
|
|
|
|
<entry>CIDR Input</entry>
|
|
|
|
<entry>CIDR Displayed</entry>
|
|
|
|
</row>
|
|
|
|
</thead>
|
|
|
|
<tbody>
|
2000-10-04 17:47:45 +02:00
|
|
|
<row>
|
|
|
|
<entry>192.168.100.128/25</entry>
|
|
|
|
<entry>192.168.100.128/25</entry>
|
|
|
|
</row>
|
2000-11-10 21:13:27 +01:00
|
|
|
<row>
|
|
|
|
<entry>192.168/24</entry>
|
|
|
|
<entry>192.168.0/24</entry>
|
|
|
|
</row>
|
2000-10-04 17:47:45 +02:00
|
|
|
<row>
|
|
|
|
<entry>192.168/25</entry>
|
|
|
|
<entry>192.168.0.0/25</entry>
|
|
|
|
</row>
|
1998-12-18 17:11:12 +01:00
|
|
|
<row>
|
|
|
|
<entry>192.168.1</entry>
|
|
|
|
<entry>192.168.1/24</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>192.168</entry>
|
|
|
|
<entry>192.168.0/24</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>128.1</entry>
|
|
|
|
<entry>128.1/16</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>128</entry>
|
|
|
|
<entry>128.0/16</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>128.1.2</entry>
|
|
|
|
<entry>128.1.2/24</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>10.1.2</entry>
|
|
|
|
<entry>10.1.2/24</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>10.1</entry>
|
|
|
|
<entry>10.1/16</entry>
|
|
|
|
</row>
|
|
|
|
<row>
|
|
|
|
<entry>10</entry>
|
|
|
|
<entry>10/8</entry>
|
|
|
|
</row>
|
|
|
|
</tbody>
|
|
|
|
</tgroup>
|
|
|
|
</table>
|
|
|
|
</para>
|
2000-11-11 20:50:31 +01:00
|
|
|
</sect2>
|
|
|
|
|
2000-11-12 00:27:48 +01:00
|
|
|
<sect2 id="inet-vs-cidr">
|
|
|
|
<title><type>inet</type> vs <type>cidr</type></title>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
<para>
|
2000-11-10 21:13:27 +01:00
|
|
|
The essential difference between <type>inet</type> and <type>cidr</type>
|
|
|
|
data types is that <type>inet</type> accepts values with nonzero bits to
|
|
|
|
the right of the netmask, whereas <type>cidr</type> does not.
|
|
|
|
|
|
|
|
<tip>
|
|
|
|
<para>
|
|
|
|
If you do not like the output format for <type>inet</type> or
|
|
|
|
<type>cidr</type> values, try the <function>host</>() and
|
|
|
|
<function>text</>() functions.
|
|
|
|
</para>
|
|
|
|
</tip>
|
1999-08-06 15:43:42 +02:00
|
|
|
</para>
|
|
|
|
</sect2>
|
2000-10-04 17:47:45 +02:00
|
|
|
|
|
|
|
<sect2 id="macaddr-type">
|
|
|
|
<title><type>macaddr</></>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The <type>macaddr</> type stores MAC addresses, i.e., Ethernet
|
|
|
|
card hardware addresses (although MAC addresses are used for
|
|
|
|
other purposes as well). Input is accepted in various customary
|
|
|
|
formats, including <literal>'08002b:010203'</>,
|
|
|
|
<literal>'08002b-010203'</>, <literal>'0800.2b01.0203'</>,
|
|
|
|
<literal>'08-00-2b-01-02-03'</>, and
|
|
|
|
<literal>'08:00:2b:01:02:03'</>, which would all specify the same
|
|
|
|
address. Upper and lower case is accepted for the digits
|
|
|
|
<literal>a</> through <literal>f</>. Output is always in the
|
|
|
|
latter of the given forms.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
1999-08-06 15:43:42 +02:00
|
|
|
</sect1>
|
|
|
|
|
|
|
|
</chapter>
|
1998-12-18 17:11:12 +01:00
|
|
|
|
|
|
|
<!-- Keep this comment at the end of the file
|
|
|
|
Local variables:
|
2000-03-31 05:27:42 +02:00
|
|
|
mode:sgml
|
1999-02-13 04:42:10 +01:00
|
|
|
sgml-omittag:nil
|
1998-12-18 17:11:12 +01:00
|
|
|
sgml-shorttag:t
|
|
|
|
sgml-minimize-attributes:nil
|
|
|
|
sgml-always-quote-attributes:t
|
|
|
|
sgml-indent-step:1
|
|
|
|
sgml-indent-data:t
|
|
|
|
sgml-parent-document:nil
|
|
|
|
sgml-default-dtd-file:"./reference.ced"
|
|
|
|
sgml-exposed-tags:nil
|
2000-03-31 05:27:42 +02:00
|
|
|
sgml-local-catalogs:("/usr/lib/sgml/catalog")
|
1998-12-18 17:11:12 +01:00
|
|
|
sgml-local-ecat-files:nil
|
|
|
|
End:
|
|
|
|
-->
|