database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-26 12:21:12 +03:00
Code Activity

Improve documentation about CREATE TABLE ... LIKE.

Browse Source 
The docs failed to explain that LIKE INCLUDING INDEXES would not preserve
the names of indexes and associated constraints.  Also, it wasn't mentioned
that EXCLUDE constraints would be copied by this option.  The latter
oversight seems enough of a documentation bug to justify back-patching.

In passing, do some minor copy-editing in the same area, and add an entry
for LIKE under "Compatibility", since it's not exactly a faithful
implementation of the standard's feature.

Discussion: <20160728151154.AABE64016B@smtp.hushmail.com>
This commit is contained in:
Tom Lane
2016-07-28 13:26:59 -04:00
parent ce10086168
commit f0795b3949
2 changed files with 38 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
doc/src/sgml/ref/create_table.sgml
View File

@ -321,26 +321,33 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
table.
</para>
<para>
Default expressions for the copied column definitions will only be
copied if <literal>INCLUDING DEFAULTS</literal> is specified. The
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</>, may create a functional linkage between
the original and new tables.
</para>
<para>
Not-null constraints are always copied to the new table.
<literal>CHECK</literal> constraints will only be copied if
<literal>INCLUDING CONSTRAINTS</literal> is specified; other types of
constraints will never be copied. Also, no distinction is made between
column constraints and table constraints &mdash; when constraints are
requested, all check constraints are copied.
<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>
Any indexes on the original table will not be created on the new
table, unless the <literal>INCLUDING INDEXES</literal> clause is
specified.
Indexes, <literal>PRIMARY KEY</>, <literal>UNIQUE</>,
and <literal>EXCLUDE</> 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</> settings for the copied column definitions will only
be copied if <literal>INCLUDING STORAGE</literal> is specified. The
<para>
<literal>STORAGE</> 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</> settings, resulting
in the copied columns in the new table having type-specific default
settings. For more on <literal>STORAGE</> settings, see
@ -348,19 +355,20 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
</para>
<para>
Comments for the copied columns, constraints, and indexes
will only be copied if <literal>INCLUDING COMMENTS</literal>
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
<para>
<literal>INCLUDING ALL</literal> is an abbreviated form of
<literal>INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS</literal>.
</para>
<para>
Note also that unlike <literal>INHERITS</literal>, columns and
Note that unlike <literal>INHERITS</literal>, columns and
constraints copied by <literal>LIKE</> 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 signalled.
<literal>LIKE</literal> clause, an error is signaled.
</para>
</listitem>
</varlistentry>
@ -1381,6 +1389,17 @@ CREATE TABLE employees OF employee_type (
</para>
</refsect2>
<refsect2>
<title><literal>LIKE</> Clause</title>
<para>
While a <literal>LIKE</> clause exists in the SQL standard, many of the
options that <productname>PostgreSQL</productname> accepts for it are not
in the standard, and some of the standard's options are not implemented
by <productname>PostgreSQL</productname>.
</para>
</refsect2>
<refsect2>
<title><literal>WITH</> Clause</title>