From: Alvaro Herrera Date: Tue, 17 Jul 2018 04:54:53 +0000 (-0400) Subject: doc: move PARTITION OF stanza to just below PARTITION BY X-Git-Tag: REL_11_BETA3~70 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=07f303ab6076c10e36ebcf46155e6ca66fcfe56e;p=postgresql doc: move PARTITION OF stanza to just below PARTITION BY It's more logical this way, since the new ordering matches the way the tables are created; but in any case, the previous location of PARTITION OF did not appear carefully chosen anyway (since it didn't match the location in which it appears in the synopsys either, which is what we normally do.) In the PARTITION BY stanza, add a link to the partitioning section in the DDL chapter, too. Suggested-by: David G. Johnston Discussion: https://postgr.es/m/CAKFQuwY4Ld7ecxL_KAmaxwt0FUu5VcPPN2L4dh+3BeYbrdBa5g@mail.gmail.com --- diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index 2a1eac9592..56b9b7c704 100644 --- a/doc/src/sgml/ref/create_table.sgml +++ b/doc/src/sgml/ref/create_table.sgml @@ -251,6 +251,145 @@ WITH ( MODULUS numeric_literal, REM + + column_name + + + The name of a column to be created in the new table. + + + + + + data_type + + + The data type of the column. This can include array + specifiers. For more information on the data types supported by + PostgreSQL, refer to . + + + + + + COLLATE collation + + + The COLLATE clause assigns a collation to + the column (which must be of a collatable data type). + If not specified, the column data type's default collation is used. + + + + + + INHERITS ( parent_table [, ... ] ) + + + The optional INHERITS clause specifies a list of + tables from which the new table automatically inherits all + columns. Parent tables can be plain tables or foreign tables. + + + + Use of INHERITS creates a persistent relationship + between the new child table and its parent table(s). Schema + modifications to the parent(s) normally propagate to children + as well, and by default the data of the child table is included in + scans of the parent(s). + + + + If the same column name exists in more than one parent + table, an error is reported unless the data types of the columns + match in each of the parent tables. If there is no conflict, + then the duplicate columns are merged to form a single column in + the new table. If the column name list of the new table + contains a column name that is also inherited, the data type must + likewise match the inherited column(s), and the column + definitions are merged into one. If the + new table explicitly specifies a default value for the column, + this default overrides any defaults from inherited declarations + of the column. Otherwise, any parents that specify default + values for the column must all specify the same default, or an + error will be reported. + + + + CHECK constraints are merged in essentially the same way as + columns: if multiple parent tables and/or the new table definition + contain identically-named CHECK constraints, these + constraints must all have the same check expression, or an error will be + reported. Constraints having the same name and expression will + be merged into one copy. A constraint marked NO INHERIT in a + parent will not be considered. Notice that an unnamed CHECK + constraint in the new table will never be merged, since a unique name + will always be chosen for it. + + + + Column STORAGE settings are also copied from parent tables. + + + + If a column in the parent table is an identity column, that property is + not inherited. A column in the child table can be declared identity + column if desired. + + + + + + PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ opclass ] [, ...] ) + + + The optional PARTITION BY clause specifies a strategy + of partitioning the table. The table thus created is called a + partitioned table. The parenthesized list of + columns or expressions forms the partition key + for the table. When using range or hash partitioning, the partition key + can include multiple columns or expressions (up to 32, but this limit can + be altered when building PostgreSQL), but for + list partitioning, the partition key must consist of a single column or + expression. + + + + Range and list partitioning require a btree operator class, while hash + partitioning requires a hash operator class. If no operator class is + specified explicitly, the default operator class of the appropriate + type will be used; if no default operator class exists, an error will + be raised. When hash partitioning is used, the operator class used + must implement support function 2 (see + for details). + + + + A partitioned table is divided into sub-tables (called partitions), + which are created using separate CREATE TABLE commands. + The partitioned table is itself empty. A data row inserted into the + table is routed to a partition based on the value of columns or + expressions in the partition key. If no existing partition matches + the values in the new row, an error will be reported. + + + + Partitioned tables do not support EXCLUDE constraints; + however, you can define these constraints on individual partitions. + Also, while it's possible to define PRIMARY KEY + constraints on partitioned tables, creating foreign keys that + reference a partitioned table is not yet supported. + + + + See for more discussion on table + partitioning. + + + + + PARTITION OF parent_table { FOR VALUES partition_bound_spec | DEFAULT } @@ -421,140 +560,6 @@ WITH ( MODULUS numeric_literal, REM - - column_name - - - The name of a column to be created in the new table. - - - - - - data_type - - - The data type of the column. This can include array - specifiers. For more information on the data types supported by - PostgreSQL, refer to . - - - - - - COLLATE collation - - - The COLLATE clause assigns a collation to - the column (which must be of a collatable data type). - If not specified, the column data type's default collation is used. - - - - - - INHERITS ( parent_table [, ... ] ) - - - The optional INHERITS clause specifies a list of - tables from which the new table automatically inherits all - columns. Parent tables can be plain tables or foreign tables. - - - - Use of INHERITS creates a persistent relationship - between the new child table and its parent table(s). Schema - modifications to the parent(s) normally propagate to children - as well, and by default the data of the child table is included in - scans of the parent(s). - - - - If the same column name exists in more than one parent - table, an error is reported unless the data types of the columns - match in each of the parent tables. If there is no conflict, - then the duplicate columns are merged to form a single column in - the new table. If the column name list of the new table - contains a column name that is also inherited, the data type must - likewise match the inherited column(s), and the column - definitions are merged into one. If the - new table explicitly specifies a default value for the column, - this default overrides any defaults from inherited declarations - of the column. Otherwise, any parents that specify default - values for the column must all specify the same default, or an - error will be reported. - - - - CHECK constraints are merged in essentially the same way as - columns: if multiple parent tables and/or the new table definition - contain identically-named CHECK constraints, these - constraints must all have the same check expression, or an error will be - reported. Constraints having the same name and expression will - be merged into one copy. A constraint marked NO INHERIT in a - parent will not be considered. Notice that an unnamed CHECK - constraint in the new table will never be merged, since a unique name - will always be chosen for it. - - - - Column STORAGE settings are also copied from parent tables. - - - - If a column in the parent table is an identity column, that property is - not inherited. A column in the child table can be declared identity - column if desired. - - - - - - PARTITION BY { RANGE | LIST | HASH } ( { column_name | ( expression ) } [ opclass ] [, ...] ) - - - The optional PARTITION BY clause specifies a strategy - of partitioning the table. The table thus created is called a - partitioned table. The parenthesized list of - columns or expressions forms the partition key - for the table. When using range or hash partitioning, the partition key - can include multiple columns or expressions (up to 32, but this limit can - be altered when building PostgreSQL), but for - list partitioning, the partition key must consist of a single column or - expression. - - - - Range and list partitioning require a btree operator class, while hash - partitioning requires a hash operator class. If no operator class is - specified explicitly, the default operator class of the appropriate - type will be used; if no default operator class exists, an error will - be raised. When hash partitioning is used, the operator class used - must implement support function 2 (see - for details). - - - - A partitioned table is divided into sub-tables (called partitions), - which are created using separate CREATE TABLE commands. - The partitioned table is itself empty. A data row inserted into the - table is routed to a partition based on the value of columns or - expressions in the partition key. If no existing partition matches - the values in the new row, an error will be reported. - - - - Partitioned tables do not support EXCLUDE constraints; - however, you can define these constraints on individual partitions. - Also, while it's possible to define PRIMARY KEY - constraints on partitioned tables, creating foreign keys that - reference a partitioned table is not yet supported. - - - - - LIKE source_table [ like_option ... ]