From 4f1766f1ea5551dc000a105ab0380f2b6730bfdc Mon Sep 17 00:00:00 2001 From: "Thomas G. Lockhart" Date: Fri, 6 Aug 1999 13:43:42 +0000 Subject: [PATCH] Try to clarify characteristics of the SERIAL type. Fix source indenting, which does not affect output. Note: still need docs on NUMERIC and DECIMAL (and let's not talk about regression tests :() --- doc/src/sgml/datatype.sgml | 1583 ++++++++++++++++++------------------ 1 file changed, 806 insertions(+), 777 deletions(-) diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 8425bb4fa6..d0d4d27c21 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -265,247 +265,265 @@ 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 + 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 + + + +
+ - 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 + 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. - - - -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 - 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. - - - - -<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 @@ -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. - - -<productname>Postgres</productname> 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. - - -<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 + + + 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 + + + +
+ - 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), @@ -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 - - -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: - - + <type>datetime</type> + + + 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: + + 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. - - - -<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 -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. + + 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 + 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: + + 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 + + <type>abstime</type> 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. - - -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 -Postgres data type. - - - - -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 + Postgres data type. + + + + + <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 -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. - - - - -<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 + 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. + + + + + <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 ) @@ -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 - - -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 @@ -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. - - - - - - -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 @@ -1880,32 +1907,34 @@ Here are some examples: <type>inet</type> - -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. + + + + +