Numeric types consist of two- and four-byte integers and four- and eight-byte
- floating point numbers.
-
-
<productname>Postgres</productname> 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
+
<productname>Postgres</productname> 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.
+
+
+ The int8 type may not be available on all platforms since
+ it relies on compiler support for this.
+
+
+
+
The Serial 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
+
CREATE TABLE tablename (colname SERIAL);
-
+
-is equivalent to specifying:
+ 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.
+
+
-
-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:
+ 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.
+
+
+
+
-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).
- The int8 type may not be available on all platforms since
- it relies on compiler support for this.
+
<productname>Postgres</productname> 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.
+
-
-
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).
+
+
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.
-
<productname>Postgres</productname> Monetary Types
-Money
-
-
- |
- Monetary Type
- Storage
- Description
- Range
-
-
-
- |
- money
- 4 bytes
- Fixed-precision
- -21474836.48 to +21474836.47
-
-
-
-
-
+
<productname>Postgres</productname> Character Types
+ Characters
+
+
+ |
+ Character Type
+ Storage
+ Recommendation
+ Description
+
+
+
+ |
+ char
+ 1 byte
+ Single character
+
+ |
+ char(n)
+ (4+n) bytes
+ Fixed-length blank padded
+
+ |
+ text
+ (4+x) bytes
+ Best choice
+ Variable-length
+
+ |
+ varchar(n)
+ (4+n) bytes
+ Variable-length with limit
+
+
+
+
+
- numeric
- will replace the money type, and should be preferred.
+ 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.
-
-
-
-
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.
-
-
-
<productname>Postgres</productname> Character Types
-Characters
-
-
- |
- Character Type
- Storage
- Recommendation
- Description
-
-
-
- |
- char
- 1 byte
- Single character
-
- |
- char(n)
- (4+n) bytes
- Fixed-length blank padded
-
- |
- text
- (4+x) bytes
- Best choice
- Variable-length
-
- |
- varchar(n)
- (4+n) bytes
- Variable-length with limit
-
-
-
-
-
-
-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.
-
-
-
<productname>Postgres</productname> Specialty Character Type
-Specialty Characters
-
-
- |
- Character Type
- Storage
- Description
-
-
-
- |
- name
- 32 bytes
- Thirty-two character internal type
-
-
-
-
-
-
-
+
<productname>Postgres</productname> Specialty Character Type
+ Specialty Characters
+
+
+ |
+ Character Type
+ Storage
+ Description
+
+
+
+ |
+ name
+ 32 bytes
+ Thirty-two character internal type
+
+
+
+
+
+
+
Date/Time Types
-
-
Date/Time Styles
-
-Output formats can be set to one of four styles:
-ISO-8601,
SQL (Ingres), traditional
-Postgres, and German.
-
-
<productname>Postgres</productname> Date Styles
-Styles
-
-
- |
- Style Specification
- Description
- Example
-
-
-
- |
- ISO
- ISO-8601 standard
- 1997-12-17 07:37:16-08
-
- |
- 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.
-
-
<productname>Postgres</productname> 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
+
+ Output formats can be set to one of four styles:
+ ISO-8601,
SQL (Ingres), traditional
+ Postgres, and German.
+
+
<productname>Postgres</productname> Date Styles
+ Styles
+
+
+ |
+ Style Specification
+ Description
+ Example
+
+
+
+ |
+ ISO
+ ISO-8601 standard
+ 1997-12-17 07:37:16-08
+
+ |
+ 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
+
+
+
+
+
- For
Postgres v6.4 (and earlier)
+ 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
+ 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),
sets the time zone for the session.
-
+
+
If an invalid time zone is specified,
-
<span class="marked">datetime</span>
-
-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
-
-
-datetime is specified using the following syntax:
-
+
<span class="marked"><type>datetime</type></span>
+
+ 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
+
+
+ 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 ]
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.
-
-
-
-
<type>timespan</type>
-
-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
-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.
+ 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.
+
-Time span is specified with the following syntax:
+ >
+
<type>timespan</type>
+ 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
+ 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:
+
Quantity Unit [Quantity Unit...] [Direction]
@ Quantity Unit [Direction]
where
Unit is second, minute, hour, day, week, month, year,
decade, century, millenium, or abbreviations or plurals of these units.
Direction is ago.
-
-
-
+
+
+
-
-abstime</span>
+
+ <type>abstime</type></span>
Absolute time (abstime) is a limited-range (+/- 68 years) and
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
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.
-
-
-All special values allowed for datetime are also
-allowed for "absolute time".
-
-
-
-
-
-
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.
-
-
-reltime shares input and output routines with the other
-time span types.
-The section on timespan covers this in more detail.
-
-
-
-
-
-
<type>timestamp</type>
-
-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.
-
-
-
-
-
<type>interval</type>
-
-
interval is an
SQL92 data type which is
-currently mapped to the timespan
-
-
-
-
-
tinterval
-
-Time ranges are specified as:
-
+
+
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".
+
+
+
+
+
+
<type>reltime</type>
+
+ 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.
+
+
+
+
+
+
<type>timestamp</type>
+
+ 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.
+
+
+
+
+
<type>interval</type>
+
+
interval is an
SQL92 data type which is
+ currently mapped to the timespan
+
+
+
+
+
<type>tinterval</type>
+
+ 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.
-
-
-
-
-
-
Boolean Type
-
-
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;
-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.
-
-
-
<productname>Postgres</productname> 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 represent two-dimensional spatial objects.
-The most fundamental type,
-the point, forms the basis for all of the other types.
-
-
-
<productname>Postgres</productname> 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.
-
-
-
-
Point
+
+
+ Special abstime values such as
+ current, infinity and
+ -infinity can be used.
+
+
+
+
+
+
+
Boolean Type
+
+
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;
+ 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.
+
+
+
<productname>Postgres</productname> 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 represent two-dimensional spatial objects.
+ The most fundamental type,
+ the point, forms the basis for all of the other types.
+
+
+
<productname>Postgres</productname> 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.
+
+
+
+
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.
-
-
-
-
-
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.
-
-
-path is specified using the following syntax:
-
+
+
+ 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
+
+ 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:
+
( ( x1 , y1 ) , ... , ( xn , yn ) )
[ ( x1 , y1 ) , ... , ( xn , yn ) ]
( x1 , y1 ) , ... , ( xn , yn )
(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
-
-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:
-
+
+
+ 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
+
+ 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
where
(x,y) is the center of the circle
r is the radius of the circle
-
-
-Circles are output using the first syntax.
-
-
-
-
-
-
-
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.
-
-
-
<productname>Postgres</productname>IP 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
-
-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:
+
+
+ Circles are output using the first syntax.
+
+
+
+
+
+
+
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.
+
+
+
<productname>Postgres</productname>IP 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
+
+ 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:
<productname>Postgres</productname>IP Types 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.
+
+
+
+
+
projects / postgresql.git / commitdiff