-Describes the built-in data types available in
Postgres.
+Describes the built-in data types available in
-
Postgres has a rich set of native data types available to users.
+
Postgres has a rich set of native data
+types available to users.
Users may add new types to
Postgres using the
define type
command described elsewhere.
-In the context of data types, the following sections will discuss SQL standards
-compliance, porting issues, and usage.
+In the context of data types, the following sections will discuss
+
SQL standards compliance, porting issues, and usage.
-Some
Postgres types correspond directly to SQL92-compatible types. In other
-cases, data types defined by SQL92 syntax are mapped directly
+Some
Postgres types correspond directly to
+
SQL92-compatible types. In other
+cases, data types defined by
SQL92 syntax are mapped directly
into native
Postgres types.
Many of the built-in types have obvious external formats. However, several
-types are either unique to
Postgres, such as open and closed paths, or have
+types are either unique to
Postgres,
+such as open and closed paths, or have
several possibilities for formats, such as date and time types.
numeric(p,s)
exact numeric for p == 9, s = 0
+ |
+ int8
+
+ signed 8-byte integer
+
|
line
closed geometric path in 2D plane
+ |
+ serial
+
+ unique id for indexing and cross-reference
+
|
time
time
-
Postgres has features at the forefront of ORDBMS development. In addition to
-SQL3 conformance, substantial portions of SQL92 are also supported.
-Although we strive for SQL92 compliance, there are some aspects of the standard
+
Postgres has features at the forefront of
+
ORDBMS development. In addition to
+
SQL3 conformance, substantial portions
+of
SQL92 are also supported.
+Although we strive for
SQL92 compliance,
+there are some aspects of the standard
which are ill considered and which should not live through subsequent standards.
-
Postgres will not make great efforts to conform to these aspects;
-however, these
-tend to apply in little-used or obsure cases, and a typical user is not likely to
-run into them.
+
Postgres will not make great efforts to
+conform to these features; however, these tend to apply in little-used
+or obsure cases, and a typical user is not likely to run into them.
Most of the input and output functions corresponding to the
The original
Postgres v4.2 code received from
Berkeley rounded all double precision floating point results to six digits for
output. Starting with v6.1, floating point numbers are allowed to retain
-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
+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
types) carry similar precision.
+ |
+ float4
+ 4 bytes
+ Variable-precision
+ 6 decimal places
+
+ |
+ float8
+ 8 bytes
+ Variable-precision
+ 15 decimal places
+
|
int2
2 bytes
+/- > 18 decimal places
|
- float4
+ serial
4 bytes
- Variable-precision
- 6 decimal places
-
- |
- float8
- 8 bytes
- Variable-precision
- 15 decimal places
+ Identifer or cross-reference
+ 0 to +2147483647
+The numeric types have a full set of corresponding arithmetic operators and
+functions. Refer to
+and for more information.
+
+The serial type is a special-case type constructed by
+
Postgres from other existing components.
+It is typically used to create unique identifiers for table entries.
+In the current implementation, specifying
+
+CREATE TABLE tablename (colname SERIAL);
+
+
+is equivalent to specifying:
+
+CREATE SEQUENCE tablename_colname_seq;
+CREATE TABLE tablename
+ (colname INT4 DEFAULT nextval('tablename_colname_seq');
+CREATE UNIQUE INDEX tablename_colname_key on tablename (colname);
+
+
+
+The implicit sequence created for the serial type will
+not be automatically removed when the table is dropped.
+So, the following commands executed in order will likely fail:
+
+CREATE TABLE tablename (colname SERIAL);
+DROP TABLE tablename;
+CREATE TABLE tablename (colname SERIAL);
+
+
+The sequence will remain in the database until explicitly dropped using
+DROP SEQUENCE.
+
+
-The exact numerics decimal and numeric
-have fully implemented syntax but currently (
Postgres v6.3)
+The exact numerics decimal and
+numeric
+have fully implemented syntax but currently
support only a small range of precision and/or range values.
-The int8 type may not be available on all platforms.
+The int8 type may not be available on all platforms since
+it relies on compiler support for this.
Monetary Type
-The money type supports US-style currency with fixed decimal point representation.
-If
Postgres is compiled with USE_LOCALE then the money type
-should use the monetary conventions defined for locale(7).
+The money type supports US-style currency with
+fixed decimal point representation.
+If
Postgres is compiled with USE_LOCALE
+then the money type
+should use the monetary conventions defined for
+ locale(7).
-The numeric>
+numeric>
should eventually replace the money type. It has a
-fully implemented syntax but currently (
Postgres v6.3)
- support only a small range of precision and/or range values and cannot substitute for
-the money type.
+fully implemented syntax but currently
+ support only a small range of precision and/or range values
+and cannot adequately substitute for the money type.
Character Types
-
SQL92 defines two primary character types:
char and
-
varchar.
Postgres supports these types, in
-addition to the more general text type, which unlike varchar
+
SQL92 defines two primary character types:
+ char and varchar.
+
Postgres supports these types, in
+addition to the more general text type,
+which unlike varchar
does not require an upper
limit to be declared on the size of the field.
|
char
1 byte
- SQL92-compatible
Single character
|
char(n)
(4+n) bytes
- SQL92-compatible
Fixed-length blank padded
|
|
varchar(n)
(4+n) bytes
- SQL92-compatible
Variable-length with limit
-There is currently one other fixed-length character type. The name type
-only has one purpose and that is to provide
Postgres with a
-special type to use for internal names. It is not intended for use by the general user.
-It's length is currently defined as 32 chars but should be reference using NAMEDATALEN.
+There is one other fixed-length character type.
+The name type
+only has one purpose and that is to provide
+special type to use for internal names.
+It is not intended for use by the general user.
+It's length is currently defined as 32 chars
+but should be reference using NAMEDATALEN.
This is set at compile time and may change in a future release.
Date/Time Types
-There are two fundamental kinds of date and time measurements: clock time and time interval.
+There are two fundamental kinds of date and time measurements:
+ clock time and time interval.
Both quantities have continuity and smoothness, as does time itself.
-
Postgres supplies two primary user-oriented date and time types,
-datetime and timespan, as well as the related SQL92 types date and time.
+
Postgres supplies two primary user-oriented
+date and time types,
+datetime and timespan, as well as
+the related
SQL92 types date and time.
|
date
4 bytes
- SQL92 type
wide range
|
|
interval
12 bytes
- SQL92 type
equivalent to timespan
|
|
time
4 bytes
- SQL92 type
wide range
|
|
timestamp
4 bytes
- SQL92 type
limited range
|
date
4713 BC
- no limit
+ 32767 AD
1 day
|
datetime
4713 BC
- no limit
+ 1465001 AD
1 microsec to 14 digits
|
interval
- no limit
- no limit
+ -178000000 years
+ 178000000 years
1 microsec
|
|
timespan
- no limit
- no limit
+ -178000000 years
+ 178000000 years
1 microsec (14 digits)
|
Postgres endevours to be compatible with
SQL92 definitions for typical usage.
The
SQL92 standard has an odd mix of date and
-time types and capabilities. For example, although the date type does not have an associated time zone, the
-time type can. The default time zone is specified as a constant offset from GMT/UTC;
- however, time zones in the real world can have no meaning unless associated with a
- date as well
+time types and capabilities. For example, although the date type
+does not have an associated time zone, the
+time type can. The default time zone is specified as a constant offset
+from GMT/UTC;
+ however, time zones in the real world can have no meaning unless
+associated with a date as well
as a time since the offset will vary through the year.
-To obviate these difficulties,
Postgres associates time zones
- only with date and time
-types which contain both date and time, and assumes local time for any type containing only
-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.
-
-In future releases, the number of date/time types will decrease, with the current
-implementation of datetime becoming timestamp, timespan becoming interval,
-and (possibly) abstime
-and reltime being deprecated in favor of timestamp and interval.
-The more arcane features
-of the date/time definitions from the
SQL92 standard are not likely to be pursued.
+To address these difficulties,
Postgres +associates time zones only with date and time
+types which contain both date and time,
+ and assumes local time for any type containing only
+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.
+
+In future releases, the number of date/time types will decrease,
+with the current implementation of
+datetime becoming timestamp,
+timespan becoming interval,
+and (possibly) abstime and reltime
+being deprecated in favor of timestamp and interval.
+The more arcane features of the date/time definitions from
+the
SQL92 standard are not likely to be pursued.
Output formats can be set to one of four styles:
-ISO-8601, SQL (Ingres), traditional
+ISO-8601,
SQL (Ingres), traditional
Postgres, and German.
1997-12-17 07:37:16-08
|
- SQL
Traditional style
12/17/1997 07:37:16.00 PST
-The SQL style has European and non-European (US) variants, which determines whether
-month follows day or vica versa.
+The
SQL style has European and non-European (US) variants, +which determines whether month follows day or vica versa.
<ProductName>Postgres</ProductName> Date Order Conventions
-The PGDATESTYLE environment variable used by the backend directly on postmaster startup.
+The PGDATESTYLE environment variable used by the backend directly
+on postmaster startup.
-The PGDATESTYLE environment variable used by the frontend libpq on session startup.
+The PGDATESTYLE environment variable used by the frontend libpq
+on session startup.
-For
Postgres v6.3 (and earlier) the default date/time style is
-"non-European traditional Postgres". In future releases, the default may become ISO-8601, which alleviates
+For
Postgres v6.4 (and earlier)
+the default date/time style is
+"non-European traditional Postgres".
+In future releases, the default may become ISO-8601, which alleviates
date specification ambiguities and Y2K collation problems.
Time Zones
-
Postgres obtains time zone support from the underlying operating system.
-All dates and times are stored internally in Universal Coordinated Time (UTC), alternately known as
-Greenwich Mean Time (GMT). Times are converted to local time on the database server before being
+
Postgres obtains time zone support
+from the underlying operating system.
+All dates and times are stored internally in Universal Coordinated Time (UTC),
+ alternately known as Greenwich Mean Time (GMT).
+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.
-The PGTZ environment variable set at the client used by libpq to send time zone information to the backend upon connection.
+The PGTZ environment variable set at the client used by libpq
+to send time zone information to the backend upon connection.
-
set timezone SQL sets the time zone for the session.
+The
SQL command
SET TIME ZONE+sets the time zone for the session.
General-use date and time is input using a wide range of
-styles, including ISO-compatible, SQL-compatible, traditional
+styles, including ISO-compatible,
SQL-compatible, and other permutations of date and time. In cases where interpretation
-can be ambiguous (quite possible with many traditional styles of date specification)
-
Postgres uses a style setting to resolve the ambiguity.
+can be ambiguous (quite possible with many traditional styles of date
+specification)
Postgres uses a style setting
+to resolve the ambiguity.
Most date and time types share code for data input. For those types
-the input can have any of a wide variety of styles. For numeric date representations,
-European and US conventions can differ, and the proper interpretation is obtained
+the input can have any of a wide variety of styles. For numeric date
+representations,
+European and US conventions can differ, and the proper interpretation
+is obtained
by using the
set datestyle
command before entering data.
-Note that the style setting does not preclude use of various styles for input; it is
+Note that the style setting does not preclude use of various styles for input;
+ it is
used primarily to determine the output style and to resolve ambiguities.
General-use date and time is input using a wide range of
-styles, including ISO-compatible, SQL-compatible, traditional
+styles, including ISO-compatible,
SQL-compatible, traditional
Postgres (see section on "absolute time")
and other permutations of date and time. Output styles can be ISO-compatible,
-SQL-compatible, or traditional
Postgres, with the default set to be compatible
+
SQL-compatible, or traditional
+
Postgres, with the default set to be compatible
General-use time span is input using a wide range of
-syntaxes, including ISO-compatible, SQL-compatible, traditional
+syntaxes, including ISO-compatible,
SQL-compatible,
+traditional
Postgres (see section on "relative time")
and other permutations of time span. Output formats can be ISO-compatible,
-SQL-compatible, or traditional
Postgres, with the default set to be
Postgres-compatible.
+
SQL-compatible, or traditional
+with the default set to be
Postgres-compatible.
Months and years are a "qualitative" time interval, and are stored separately
-from the other "quantitative" time intervals such as day or hour. For date arithmetic,
-the qualitative time units are instantiated in the context of the relevant date or time.
+from the other "quantitative" time intervals such as day or hour.
+For date arithmetic,
+the qualitative time units are instantiated in the context of the
+relevant date or time.
Time span is specified with the following syntax:
abstime
-Absolute time (abstime) is a limited-range (+/- 68 years) and limited-precision (1 sec)
+Absolute time (abstime) is a limited-range (+/- 68 years) and
+limited-precision (1 sec)
date data type. datetime may be preferred, since it
covers a larger range with greater precision.
Valid dates are from Dec 13 20:45:53 1901 GMT to Jan 19 03:14:04
-2038 GMT. As of Version 3.0, times are no longer read and written
+2038 GMT.
+
+
+
Historical Note
+As of Version 3.0, times are no longer read and written
using Greenwich Mean Time; the input and output routines default to
the local time zone.
+
-All special values allowed for datetime are also allowed for "absolute time".
+All special values allowed for datetime are also
+allowed for "absolute time".
Relative time reltime is a limited-range (+/- 68 years)
and limited-precision (1 sec) time span data type.
timespan should be preferred, since it
-covers a larger range with greater precision and, more importantly, can distinguish between
-relative units (months and years) and quantitative units (days, hours, etc). Instead, reltime
-must force months to be exactly 30 days, so time arithmetic does not always work as expected.
-For example, adding one reltime year to abstime today does not produce today's date one year from
+covers a larger range with greater precision and, more importantly,
+can distinguish between
+relative units (months and years) and quantitative units (days, hours, etc).
+Instead, reltime
+must force months to be exactly 30 days, so time arithmetic does not
+always work as expected.
+For example, adding one reltime year to abstime today does not
+produce today's date one year from
now, but rather a date 360 days from today.
-reltime shares input and output routines with the other time span types.
+reltime shares input and output routines with the other
+time span types.
The section on timespan covers this in more detail.
This is currently a limited-range absolute time which closely resembles the
abstime
data type. It shares the general input parser with the other date/time types.
-In future releases this type will absorb the capabilities of the datetime type
-and will move toward SQL92 compliance.
+In future releases this type will absorb the capabilities of the
+datetime type
+and will move toward
SQL92 compliance.
-timestamp is specified using the same syntax as for datetime.
+timestamp is specified using the same syntax as for
+datetime.
interval is an
SQL92 data type which is
-currently mapped to the
timespan Postgres-data type.
+currently mapped to the timespan
Postgres supports
bool as
-bool can have one of only two states: 'true' or 'false'. A third state, 'unknown', is not
-implemented and is not suggested in
SQL3;
NULL is an
-effective substitute. bool can be used in any boolean expression, and boolean expressions
+bool can have one of only two states: 'true' or 'false'.
+A third state, 'unknown', is not
+implemented and is not suggested in
SQL3;
+effective substitute. bool can be used in any boolean expression,
+and boolean expressions
always evaluate to a result compatible with this type.
Geometric Types
-Geometric types represent two-dimensional spatial objects. The most fundamental type,
+Geometric types represent two-dimensional spatial objects.
+The most fundamental type,
the point, forms the basis for all of the other types.
A rich set of functions and operators is available to perform various geometric
-operations such as scaling, translation, rotation, and determining intersections.
+operations such as scaling, translation, rotation, and determining
+intersections.
Paths are output using the first syntax.
Note that
Postgres versions prior to
-v6.1 used a format for paths which had a single leading parenthesis, a "closed" flag,
+v6.1 used a format for paths which had a single leading parenthesis,
+a "closed" flag,
an integer count of the number of points, then the list of points followed by a
-closing parenthesis. The built-in function upgradepath is supplied to convert
+closing parenthesis.
+The built-in function upgradepath is supplied to convert
paths dumped and reloaded from pre-v6.1 databases.
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.
+considered equivalent to closed paths, but are stored differently
+and have their own set of support routines.
Polygons are output using the first syntax.
Note that
Postgres versions prior to
v6.1 used a format for polygons which had a single leading parenthesis, the list
-of x-axis coordinates, the list of y-axis coordinates, followed by a closing parenthesis.
+of x-axis coordinates, the list of y-axis coordinates,
+followed by a closing parenthesis.
The built-in function upgradepoly is supplied to convert
polygons dumped and reloaded from pre-v6.1 databases.
projects / postgresql.git / commitdiff