diff options
| -rw-r--r-- | doc/src/sgml/ref/create_table.sgml | 168 |
1 files changed, 113 insertions, 55 deletions
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index 2a1eac9592b..b4495209409 100644 --- a/doc/src/sgml/ref/create_table.sgml +++ b/doc/src/sgml/ref/create_table.sgml @@ -570,67 +570,125 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM possible to include data of the new table in scans of the original table. </para> - <para> - Default expressions for the copied column definitions will be copied - only if <literal>INCLUDING DEFAULTS</literal> is specified. The - default behavior is to exclude default expressions, resulting in the - copied columns in the new table having null defaults. - Note that copying defaults that call database-modification functions, - such as <function>nextval</function>, may create a functional linkage between - the original and new tables. - </para> - <para> - Any identity specifications of copied column definitions will only be - copied if <literal>INCLUDING IDENTITY</literal> is specified. A new - sequence is created for each identity column of the new table, separate - from the sequences associated with the old table. - </para> - <para> - Not-null constraints are always copied to the new table. - <literal>CHECK</literal> constraints will be copied only if - <literal>INCLUDING CONSTRAINTS</literal> is specified. - No distinction is made between column constraints and table - constraints. - </para> - <para> - Extended statistics are copied to the new table if - <literal>INCLUDING STATISTICS</literal> is specified. - </para> - <para> - Indexes, <literal>PRIMARY KEY</literal>, <literal>UNIQUE</literal>, - and <literal>EXCLUDE</literal> constraints on the original table will be - created on the new table only if <literal>INCLUDING INDEXES</literal> - is specified. Names for the new indexes and constraints are - chosen according to the default rules, regardless of how the originals - were named. (This behavior avoids possible duplicate-name failures for - the new indexes.) - </para> - <para> - <literal>STORAGE</literal> settings for the copied column definitions will be - copied only if <literal>INCLUDING STORAGE</literal> is specified. The - default behavior is to exclude <literal>STORAGE</literal> settings, resulting - in the copied columns in the new table having type-specific default - settings. For more on <literal>STORAGE</literal> settings, see - <xref linkend="storage-toast"/>. - </para> - <para> - Comments for the copied columns, constraints, and indexes - will be copied only if <literal>INCLUDING COMMENTS</literal> - is specified. The default behavior is to exclude comments, resulting in - the copied columns and constraints in the new table having no comments. - </para> - <para> - <literal>INCLUDING ALL</literal> is an abbreviated form of - <literal>INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING INDEXES INCLUDING STATISTICS INCLUDING STORAGE</literal>. - </para> - <para> - Note that unlike <literal>INHERITS</literal>, columns and + <para> + Also unlike <literal>INHERITS</literal>, columns and constraints copied by <literal>LIKE</literal> are not merged with similarly named columns and constraints. If the same name is specified explicitly or in another <literal>LIKE</literal> clause, an error is signaled. </para> <para> + The optional <replaceable>like_option</replaceable> clauses specify + which additional properties of the original table to copy. Specifying + <literal>INCLUDING</literal> copies the property, specifying + <literal>EXCLUDING</literal> omits the property. + <literal>EXCLUDING</literal> is the default. If multiple specifications + are made for the same kind of object, the last one is used. The + available options are: + + <variablelist> + <varlistentry> + <term><literal>INCLUDING COMMENTS</literal></term> + <listitem> + <para> + Comments for the copied columns, constraints, and indexes will be + copied. The default behavior is to exclude comments, resulting in + the copied columns and constraints in the new table having no + comments. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING CONSTRAINTS</literal></term> + <listitem> + <para> + <literal>CHECK</literal> constraints will be copied. No distinction + is made between column constraints and table constraints. Not-null + constraints are always copied to the new table. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING DEFAULTS</literal></term> + <listitem> + <para> + Default expressions for the copied column definitions will be + copied. Otherwise, default expressions are not copied, resulting in + the copied columns in the new table having null defaults. Note that + copying defaults that call database-modification functions, such as + <function>nextval</function>, may create a functional linkage + between the original and new tables. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING IDENTITY</literal></term> + <listitem> + <para> + Any identity specifications of copied column definitions will be + copied. A new sequence is created for each identity column of the + new table, separate from the sequences associated with the old + table. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING INDEXES</literal></term> + <listitem> + <para> + Indexes, <literal>PRIMARY KEY</literal>, <literal>UNIQUE</literal>, + and <literal>EXCLUDE</literal> constraints on the original table + will be created on the new table. Names for the new indexes and + constraints are chosen according to the default rules, regardless of + how the originals were named. (This behavior avoids possible + duplicate-name failures for the new indexes.) + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING STATISTICS</literal></term> + <listitem> + <para> + Extended statistics are copied to the new table. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING STORAGE</literal></term> + <listitem> + <para> + <literal>STORAGE</literal> settings for the copied column + definitions will be copied. The default behavior is to exclude + <literal>STORAGE</literal> settings, resulting in the copied columns + in the new table having type-specific default settings. For more on + <literal>STORAGE</literal> settings, see <xref + linkend="storage-toast"/>. + </para> + </listitem> + </varlistentry> + + <varlistentry> + <term><literal>INCLUDING ALL</literal></term> + <listitem> + <para> + <literal>INCLUDING ALL</literal> is an abbreviated form selecting + all the available individual options. (It could be useful to write + individual <literal>EXCLUDING</literal> clauses after + <literal>INCLUDING ALL</literal> to select all but some specific + options.) + </para> + </listitem> + </varlistentry> + </variablelist> + </para> + + <para> The <literal>LIKE</literal> clause can also be used to copy column definitions from views, foreign tables, or composite types. Inapplicable options (e.g., <literal>INCLUDING INDEXES</literal> from |