diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 8425bb4fa6e..d0d4d27c219 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -265,103 +265,68 @@
Numeric types consist of two- and four-byte integers and four- and eight-byte
- floating point numbers.
-
-
-
-Postgres Numeric Types
-Numerics
-
-
-
- Numeric Type
- Storage
- Description
- Range
-
-
-
-
- float4
- 4 bytes
- Variable-precision
- 6 decimal places
-
-
- float8
- 8 bytes
- Variable-precision
- 15 decimal places
-
-
- int2
- 2 bytes
- Fixed-precision
- -32768 to +32767
-
-
- int4
- 4 bytes
- Usual choice for fixed-precision
- -2147483648 to +2147483647
-
-
- int8
- 8 bytes
- Very large range fixed-precision
- +/- > 18 decimal places
-
-
- serial
- 4 bytes
- 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.
+ floating point numbers.
-
-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
+
+
+ Postgres Numeric Types
+ Numerics
+
+
+
+ Numeric Type
+ Storage
+ Description
+ Range
+
+
+
+
+ float4
+ 4 bytes
+ Variable-precision
+ 6 decimal places
+
+
+ float8
+ 8 bytes
+ Variable-precision
+ 15 decimal places
+
+
+ int2
+ 2 bytes
+ Fixed-precision
+ -32768 to +32767
+
+
+ int4
+ 4 bytes
+ Usual choice for fixed-precision
+ -2147483648 to +2147483647
+
+
+ int8
+ 8 bytes
+ Very large range fixed-precision
+ +/- > 18 decimal places
+
+
+ serial
+ 4 bytes
+ Identifer or cross-reference
+ 0 to +2147483647
+
+
+
+
+
-
-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 numeric types have a full set of corresponding arithmetic operators and
+ functions. Refer to
+ and for more information.
@@ -369,143 +334,196 @@ The sequence will remain in the database until explicitly dropped using
it relies on compiler support for this.
-
+
+ The Serial Type
-
-Monetary Type
+
+ 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
-
-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).
+
+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.
+
+
+
+ Implicit sequences supporting the serial are
+ not automatically dropped when a table containing a serial type
+ 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.
+
+
+
+
+
+
+ Monetary Type
+
+
+ Obsolete Type
+
+ The money is now obsolete. Use numeric
+ or decimal instead.
+
+
+
+
+ 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).
-
-
-Postgres Monetary Types
-Money
-
-
-
- Monetary Type
- Storage
- Description
- Range
-
-
-
-
- money
- 4 bytes
- Fixed-precision
- -21474836.48 to +21474836.47
-
-
-
-
-
+
+
+ Postgres Monetary Types
+ Money
+
+
+
+ Monetary Type
+ Storage
+ Description
+ Range
+
+
+
+
+ money
+ 4 bytes
+ Fixed-precision
+ -21474836.48 to +21474836.47
+
+
+
+
+
numeric
will replace the money type, and should be preferred.
-
+
-
-Character Types
+
+ 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
-does not require an upper
-limit to be declared on the size of the field.
-
+
+ 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.
+
-
-
-Postgres Character Types
-Characters
-
-
-
- Character Type
- Storage
- Recommendation
- Description
-
-
-
-
- char
- 1 byte
- SQL92-compatible
- Single character
-
-
- char(n)
- (4+n) bytes
- SQL92-compatible
- Fixed-length blank padded
-
-
- text
- (4+x) bytes
- Best choice
- Variable-length
-
-
- varchar(n)
- (4+n) bytes
- SQL92-compatible
- Variable-length with limit
-
-
-
-
-
+
+
+ Postgres Character Types
+ Characters
+
+
+
+ Character Type
+ Storage
+ Recommendation
+ Description
+
+
+
+
+ char
+ 1 byte
+ SQL92-compatible
+ Single character
+
+
+ char(n)
+ (4+n) bytes
+ SQL92-compatible
+ Fixed-length blank padded
+
+
+ text
+ (4+x) bytes
+ Best choice
+ Variable-length
+
+
+ varchar(n)
+ (4+n) bytes
+ SQL92-compatible
+ Variable-length with limit
+
+
+
+
+
-
-There is 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.
-This is set at compile time and may change in a future release.
-
+
+ There is 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.
+ This is set at compile time and may change in a future release.
+
-
-
-Postgres Specialty Character Type
-Specialty Characters
-
-
-
- Character Type
- Storage
- Description
-
-
-
-
- name
- 32 bytes
- Thirty-two character internal type
-
-
-
-
-
+
+
+ Postgres Specialty Character Type
+ Specialty Characters
+
+
+
+ Character Type
+ Storage
+ Description
+
+
+
+
+ name
+ 32 bytes
+ Thirty-two character internal type
+
+
+
+
+
-
+
Date/Time Types
@@ -728,113 +746,113 @@ This is set at compile time and may change in a future release.
-
-Date/Time Styles
-
-
-Output formats can be set to one of four styles:
-ISO-8601, SQL (Ingres), traditional
-Postgres, and German.
-
-
-Postgres Date Styles
-Styles
-
-
-
- Style Specification
- Description
- Example
-
-
-
-
- ISO
- ISO-8601 standard
- 1997-12-17 07:37:16-08
-
-
- SQL
- Traditional style
- 12/17/1997 07:37:16.00 PST
-
-
- Postgres
- Original style
- Wed Dec 17 07:37:16 1997 PST
-
-
- German
- Regional style
- 17.12.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.
-
-
-Postgres Date Order Conventions
-Order
-
-
-
- Style Specification
- Description
- Example
-
-
-
-
- European
- Regional convention
- 17/12/1997 15:37:16.00 MET
-
-
- NonEuropean
- Regional convention
- 12/17/1997 07:37:16.00 PST
-
-
- US
- Regional convention
- 12/17/1997 07:37:16.00 PST
-
-
-
-
-
-
-
-There are several ways to affect the appearance of date/time types:
-
-
-
-
-The PGDATESTYLE environment variable used by the backend directly
-on postmaster startup.
-
-
-
-
-The PGDATESTYLE environment variable used by the frontend libpq
-on session startup.
-
-
-
-
-SET DATESTYLE SQL command.
-
-
-
-
+
+ Date/Time Styles
- For Postgres v6.4 (and earlier)
+ Output formats can be set to one of four styles:
+ ISO-8601, SQL (Ingres), traditional
+ Postgres, and German.
+
+
+ Postgres Date Styles
+ Styles
+
+
+
+ Style Specification
+ Description
+ Example
+
+
+
+
+ ISO
+ ISO-8601 standard
+ 1997-12-17 07:37:16-08
+
+
+ SQL
+ Traditional style
+ 12/17/1997 07:37:16.00 PST
+
+
+ Postgres
+ Original style
+ Wed Dec 17 07:37:16 1997 PST
+
+
+ German
+ Regional style
+ 17.12.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.
+
+
+ Postgres Date Order Conventions
+ Order
+
+
+
+ Style Specification
+ Description
+ Example
+
+
+
+
+ European
+ Regional convention
+ 17/12/1997 15:37:16.00 MET
+
+
+ NonEuropean
+ Regional convention
+ 12/17/1997 07:37:16.00 PST
+
+
+ US
+ Regional convention
+ 12/17/1997 07:37:16.00 PST
+
+
+
+
+
+
+
+ There are several ways to affect the appearance of date/time types:
+
+
+
+
+ The PGDATESTYLE environment variable used by the backend directly
+ on postmaster startup.
+
+
+
+
+ The PGDATESTYLE environment variable used by the frontend libpq
+ on session startup.
+
+
+
+
+ SET DATESTYLE SQL command.
+
+
+
+
+
+
+ For Postgres v6.5 (and earlier)
the default date/time style is
"non-European traditional Postgres".
In future releases, the default may become "ISO" (compatible with ISO-8601),
@@ -901,7 +919,8 @@ on session startup.
sets the time zone for the session.
-
+
+
If an invalid time zone is specified,
@@ -1291,22 +1310,22 @@ on session startup.
- datetime
+ datetime
-
-General-use date and time is input using a wide range of
-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
-with Postgres v6.0.
-
+
+ General-use date and time is input using a wide range of
+ 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
+ with Postgres v6.0.
+
-
-datetime is specified using the following syntax:
+
+ datetime is specified using the following syntax:
-
+
Year-Month-Day [ Hour : Minute : Second ] [AD,BC] [ Timezone ]
YearMonthDay [ Hour : Minute : Second ] [AD,BC] [ Timezone ]
Month Day [ Hour : Minute : Second ] Year [AD,BC] [ Timezone ]
@@ -1318,40 +1337,41 @@ where
Minute is 00, 01, ..., 59
Second is 00, 01, ..., 59 (60 for leap second)
Timezone is 3 characters or ISO offset to GMT
-
+
-
-Valid dates are from Nov 13 00:00:00 4013 BC GMT to far into the future.
-Timezones are either three characters (e.g. "GMT" or "PST") or ISO-compatible
-offsets to GMT (e.g. "-08" or "-08:00" when in Pacific Standard Time).
-Dates are stored internally in Greenwich Mean Time. Input and output routines
-translate time to the local time zone of the server.
-
+
+ Valid dates are from Nov 13 00:00:00 4013 BC GMT to far into the future.
+ Timezones are either three characters (e.g. "GMT" or "PST") or ISO-compatible
+ offsets to GMT (e.g. "-08" or "-08:00" when in Pacific Standard Time).
+ Dates are stored internally in Greenwich Mean Time. Input and output routines
+ translate time to the local time zone of the server.
+
+
-
-timespan
+
+ timespan
-
-General-use time span is input using a wide range of
-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.
-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.
+
+ General-use time span is input using a wide range of
+ 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.
+ 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.
-
-Time span is specified with the following syntax:
+
+ Time span is specified with the following syntax:
-
+
Quantity Unit [Quantity Unit...] [Direction]
@ Quantity Unit [Direction]
where
@@ -1359,12 +1379,12 @@ where
Unit is second, minute, hour, day, week, month, year,
decade, century, millenium, or abbreviations or plurals of these units.
Direction is ago.
-
-
-
+
+
+
-
-abstime
+
+ abstime
Absolute time (abstime) is a limited-range (+/- 68 years) and
@@ -1373,10 +1393,10 @@ where
covers a larger range with greater precision.
-
-Absolute time is specified using the following syntax:
+
+ Absolute time is specified using the following syntax:
-
+
Month Day [ Hour : Minute : Second ] Year [ Timezone ]
where
Month is Jan, Feb, ..., Dec
@@ -1385,315 +1405,318 @@ where
Minute is 00, 01, ..., 59
Second is 00, 01, ..., 59
Year is 1901, 1902, ..., 2038
-
-
+
+
-
+
Valid dates are from Dec 13 20:45:53 1901 GMT
to Jan 19 03:14:04 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.
-
+
+ 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".
+
-
+
-
-reltime
+
+ reltime
-
-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
-now, but rather a date 360 days from today.
-
+
+ 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
+ now, but rather a date 360 days from today.
+
-
-reltime shares input and output routines with the other
-time span types.
-The section on timespan covers this in more detail.
-
+
+ reltime shares input and output routines with the other
+ time span types.
+ The section on timespan covers this in more detail.
+
-
+
-
-timestamp
+
+ timestamp
-
-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.
-
+
+ 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.
+
-
-timestamp is specified using the same syntax as for
-datetime.
-
-
+
+ timestamp is specified using the same syntax as for
+ datetime.
+
+
-
-interval
+
+ interval
-
-interval is an SQL92 data type which is
-currently mapped to the timespan
-Postgres data type.
-
-
+
+ interval is an SQL92 data type which is
+ currently mapped to the timespan
+ Postgres data type.
+
+
-
-tinterval
+
+ tinterval
-
-Time ranges are specified as:
+
+ Time ranges are specified as:
-
+
[ 'abstime' 'abstime']
where
abstime is a time in the absolute time format.
-
+
-Special abstime values such as
-current', infinity' and -infinity' can be used.
-
+ Special abstime values such as
+ current, infinity and
+ -infinity can be used.
+
+
-
+
-
-Boolean Type
+
+ Boolean Type
-
-Postgres supports bool as
-the SQL3 boolean type.
-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
-always evaluate to a result compatible with this type.
+
+ Postgres supports bool as
+ the SQL3 boolean type.
+ 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
+ always evaluate to a result compatible with this type.
-
-bool uses 1 byte of storage.
-
+
+ bool uses 1 byte of storage.
+
-
-
-Postgres Boolean Type
-Booleans
-
-
-
- State
- Output
- Input
-
-
-
-
- True
- 't'
- TRUE, 't', 'true', 'y', 'yes', '1'
-
-
- False
- 'f'
- FALSE, 'f', 'false', 'n', 'no', '0'
-
-
-
-
-
-
+
+
+ Postgres Boolean Type
+ Booleans
+
+
+
+ State
+ Output
+ Input
+
+
+
+
+ True
+ 't'
+ TRUE, 't', 'true', 'y', 'yes', '1'
+
+
+ False
+ 'f'
+ FALSE, 'f', 'false', 'n', 'no', '0'
+
+
+
+
+
+
-
-Geometric Types
+
+ Geometric Types
-
-Geometric types represent two-dimensional spatial objects.
-The most fundamental type,
-the point, forms the basis for all of the other types.
-
+
+ Geometric types represent two-dimensional spatial objects.
+ The most fundamental type,
+ the point, forms the basis for all of the other types.
+
-
-
-Postgres Geometric Types
-Geometrics
-
-
-
- Geometric Type
- Storage
- Representation
- Description
-
-
-
-
- point
- 16 bytes
- (x,y)
- Point in space
-
-
- line
- 32 bytes
- ((x1,y1),(x2,y2))
- Infinite line
-
-
- lseg
- 32 bytes
- ((x1,y1),(x2,y2))
- Finite line segment
-
-
- box
- 32 bytes
- ((x1,y1),(x2,y2))
- Rectangular box
-
-
- path
- 4+32n bytes
- ((x1,y1),...)
- Closed path (similar to polygon)
-
-
- path
- 4+32n bytes
- [(x1,y1),...]
- Open path
-
-
- polygon
- 4+32n bytes
- ((x1,y1),...)
- Polygon (similar to closed path)
-
-
- circle
- 24 bytes
- <(x,y),r>
- Circle (center and radius)
-
-
-
-
-
+
+
+ Postgres Geometric Types
+ Geometrics
+
+
+
+ Geometric Type
+ Storage
+ Representation
+ Description
+
+
+
+
+ point
+ 16 bytes
+ (x,y)
+ Point in space
+
+
+ line
+ 32 bytes
+ ((x1,y1),(x2,y2))
+ Infinite line
+
+
+ lseg
+ 32 bytes
+ ((x1,y1),(x2,y2))
+ Finite line segment
+
+
+ box
+ 32 bytes
+ ((x1,y1),(x2,y2))
+ Rectangular box
+
+
+ path
+ 4+32n bytes
+ ((x1,y1),...)
+ Closed path (similar to polygon)
+
+
+ path
+ 4+32n bytes
+ [(x1,y1),...]
+ Open path
+
+
+ polygon
+ 4+32n bytes
+ ((x1,y1),...)
+ Polygon (similar to closed path)
+
+
+ circle
+ 24 bytes
+ <(x,y),r>
+ Circle (center and radius)
+
+
+
+
+
-
-A rich set of functions and operators is available to perform various geometric
-operations such as scaling, translation, rotation, and determining
-intersections.
-
+
+ A rich set of functions and operators is available to perform various geometric
+ operations such as scaling, translation, rotation, and determining
+ intersections.
+
-
-Point
+
+ Point
Points are the fundamental two-dimensional building block for geometric types.
-
-point is specified using the following syntax:
+
+ point is specified using the following syntax:
-
+
( x , y )
x , y
where
x is the x-axis coordinate as a floating point number
y is the y-axis coordinate as a floating point number
-
-
-
+
+
+
-
-Line Segment
+
+ Line Segment
-
-Line segments (lseg) are represented by pairs of points.
-
+
+ Line segments (lseg) are represented by pairs of points.
+
-
-lseg is specified using the following syntax:
-
+
+ lseg is specified using the following syntax:
+
( ( x1 , y1 ) , ( x2 , y2 ) )
( x1 , y1 ) , ( x2 , y2 )
x1 , y1 , x2 , y2
where
(x1,y1) and (x2,y2) are the endpoints of the segment
-
-
-
+
+
+
-
-Box
+
+ Box
-
-Boxes are represented by pairs of points which are opposite
-corners of the box.
-
+
+ Boxes are represented by pairs of points which are opposite
+ corners of the box.
+
-
+
box is specified using the following syntax:
-
+
( ( x1 , y1 ) , ( x2 , y2 ) )
( x1 , y1 ) , ( x2 , y2 )
x1 , y1 , x2 , y2
where
(x1,y1) and (x2,y2) are opposite corners
-
+
-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.
-
-
+ 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.
+
+
-
-Path
+
+ Path
-
-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
-popen(p)
-and
-pclose(p)
-are supplied to force a path to be open or closed, and functions
-isopen(p)
-and
-isclosed(p)
-are supplied to select either type in a query.
-
+
+ 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
+ popen(p)
+ and
+ pclose(p)
+ are supplied to force a path to be open or closed, and functions
+ isopen(p)
+ and
+ isclosed(p)
+ are supplied to select either type in a query.
+
-
-path is specified using the following syntax:
+
+ path is specified using the following syntax:
-
+
( ( x1 , y1 ) , ... , ( xn , yn ) )
[ ( x1 , y1 ) , ... , ( xn , yn ) ]
( x1 , y1 ) , ... , ( xn , yn )
@@ -1703,60 +1726,61 @@ where
(x1,y1),...,(xn,yn) are points 1 through n
a leading "[" indicates an open path
a leading "(" indicates a closed path
-
-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,
-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
-paths dumped and reloaded from pre-v6.1 databases.
-
-
+
-
-Polygon
+ 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,
+ 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
+ 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.
-
+
+ Polygon
-
-polygon is specified using the following syntax:
+
+ 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.
+
-
+
+ polygon is specified using the following syntax:
+
+
( ( x1 , y1 ) , ... , ( xn , yn ) )
( x1 , y1 ) , ... , ( xn , yn )
( x1 , y1 , ... , xn , yn )
x1 , y1 , ... , xn , yn
where
(x1,y1),...,(xn,yn) are points 1 through n
-
+
-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.
-The built-in function upgradepoly is supplied to convert
-polygons dumped and reloaded from pre-v6.1 databases.
-
-
+ 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.
+ The built-in function upgradepoly is supplied to convert
+ polygons dumped and reloaded from pre-v6.1 databases.
+
+
-
-Circle
+
+ Circle
-
-Circles are represented by a center point and a radius.
-
+
+ Circles are represented by a center point and a radius.
+
-
-circle is specified using the following syntax:
+
+ circle is specified using the following syntax:
-
+
< ( x , y ) , r >
( ( x , y ) , r )
( x , y ) , r
@@ -1764,70 +1788,73 @@ circle is specified using the following syntax:
where
(x,y) is the center of the circle
r is the radius of the circle
-
+
-Circles are output using the first syntax.
-
-
+ Circles are output using the first syntax.
+
+
-
+
-
-IP Version 4 Networks and Host Addresses
+
+ IP Version 4 Networks and Host Addresses
-
-The cidr type stores networks specified
-in CIDR (Classless Inter-Domain Routing) notation.
-The inet type stores hosts and networks in CIDR notation using a simple
-variation in representation to represent simple host TCP/IP addresses.
-
+
+ The cidr type stores networks specified
+ in CIDR (Classless Inter-Domain Routing) notation.
+ The inet type stores hosts and networks in CIDR notation using a simple
+ variation in representation to represent simple host TCP/IP addresses.
+
-
-
-PostgresIP Version 4 Types
-IPV4
-
-
-
- IPV4 Type
- Storage
- Description
- Range
-
-
-
-
- cidr
- variable
- CIDR networks
- Valid IPV4 CIDR blocks
-
-
- inet
- variable
- nets and hosts
- Valid IPV4 CIDR blocks
-
-
-
-
-
+
+
+ PostgresIP Version 4 Types
+ IPV4
+
+
+
+ IPV4 Type
+ Storage
+ Description
+ Range
+
+
+
+
+ cidr
+ variable
+ CIDR networks
+ Valid IPV4 CIDR blocks
+
+
+ inet
+ variable
+ nets and hosts
+ Valid IPV4 CIDR blocks
+
+
+
+
+
-
-CIDR
+
+ CIDR
-
-The cidr type holds a CIDR network.
-The format for specifying classless networks is x.x.x.x/y
- where x.x.x.x is the
-network and /y is the number of bits in the netmask.
-If /y omitted, it is calculated using assumptions from
-the older classfull naming system except that it is extended to include at least
-all of the octets in the input.
-
+
+ The cidr type holds a CIDR network.
+ The format for specifying classless networks is
+ x.x.x.x/y
+ where x.x.x.x is the
+ network and /y is
+ the number of bits in the netmask.
+ If /y omitted, it is
+ calculated using assumptions from
+ the older classfull naming system except that it is extended to include at least
+ all of the octets in the input.
+
-
-Here are some examples:
+
+ Here are some examples:
PostgresIP Types Examples
@@ -1880,32 +1907,34 @@ Here are some examples:
inet
-
-The inet type is designed to hold, in one field, all of the information
-about a host including the CIDR-style subnet that it is in.
-Note that if you want to store proper CIDR networks,
-you should use the cidr type.
-The inet type is similar to the cidr type except that the bits in the
-host part can be non-zero.
-Functions exist to extract the various elements of the field.
-
+
+ The inet type is designed to hold, in one field, all of the information
+ about a host including the CIDR-style subnet that it is in.
+ Note that if you want to store proper CIDR networks,
+ you should use the cidr type.
+ The inet type is similar to the cidr
+ type except that the bits in the
+ host part can be non-zero.
+ Functions exist to extract the various elements of the field.
+
-
+
The input format for this function is
- x.x.x.x/y
-where x.x.x.x is
-an internet host and y
-is the number of bits in the netmask.
-If the /y part is left off,
-it is treated as /32.
-On output, the /y part is not printed
-if it is /32.
-This allows the type to be used as a straight host type by just leaving off
-the bits part.
-
-
+ x.x.x.x/y
+ where x.x.x.x is
+ an internet host and y
+ is the number of bits in the netmask.
+ If the /y part is left off,
+ it is treated as /32.
+ On output, the /y part is not printed
+ if it is /32.
+ This allows the type to be used as a straight host type by just leaving off
+ the bits part.
+
+
+
-
+