mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-01-18 18:44:06 +08:00
Code Issues Packages Projects Releases Wiki 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 1be0387956
commit 52205629ac
2 changed files with 39 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -328,23 +328,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 be copied only if
<literal>INCLUDING CONSTRAINTS</literal> is specified.
Indexes, <literal>PRIMARY KEY</>, and <literal>UNIQUE</> constraints
on the original table will be created on the new table only if the
<literal>INCLUDING INDEXES</literal> clause is specified.
No distinction is made between column constraints and table
constraints.
</para>
<para><literal>STORAGE</> settings for the copied column definitions will only
be copied if <literal>INCLUDING STORAGE</literal> is specified. The
<para>
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 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
@ -352,24 +362,26 @@ 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 signaled.
</para>
<para>
The <literal>LIKE</literal> clause can also be used to copy columns from
views, foreign tables, or composite types. Inapplicable options (e.g., <literal>INCLUDING
INDEXES</literal> from a view) are ignored.
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
a view) are ignored.
</para>
</listitem>
</varlistentry>
@ -1444,6 +1456,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>

4
src/backend/parser/parse_utilcmd.c
View File

@ -1056,7 +1056,9 @@ generateClonedIndexStmt(CreateStmtContext *cxt, Relation source_idx,
/*
* We don't try to preserve the name of the source index; instead, just
* let DefineIndex() choose a reasonable name.
* let DefineIndex() choose a reasonable name. (If we tried to preserve
* the name, we'd get duplicate-relation-name failures unless the source
* table was in a different schema.)
*/
index->idxname = NULL;