mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-05 21:09:22 +02:00
Improve documentation about CREATE TABLE ... LIKE.
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:
parent
93b99d3b6a
commit
884aec4f85
@ -329,26 +329,33 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
|
|||||||
table.
|
table.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Default expressions for the copied column definitions will only be
|
Default expressions for the copied column definitions will be copied
|
||||||
copied if <literal>INCLUDING DEFAULTS</literal> is specified.
|
only if <literal>INCLUDING DEFAULTS</literal> is specified. The
|
||||||
Defaults that call database-modification functions, like
|
|
||||||
<function>nextval</>, create a linkage between the original and
|
|
||||||
new tables. The
|
|
||||||
default behavior is to exclude default expressions, resulting in the
|
default behavior is to exclude default expressions, resulting in the
|
||||||
copied columns in the new table having null defaults.
|
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>
|
||||||
<para>
|
<para>
|
||||||
Not-null constraints are always copied to the new table.
|
Not-null constraints are always copied to the new table.
|
||||||
<literal>CHECK</literal> constraints will be copied only if
|
<literal>CHECK</literal> constraints will be copied only if
|
||||||
<literal>INCLUDING CONSTRAINTS</literal> is specified.
|
<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
|
No distinction is made between column constraints and table
|
||||||
constraints.
|
constraints.
|
||||||
</para>
|
</para>
|
||||||
<para><literal>STORAGE</> settings for the copied column definitions will only
|
<para>
|
||||||
be copied if <literal>INCLUDING STORAGE</literal> is specified. The
|
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
|
default behavior is to exclude <literal>STORAGE</> settings, resulting
|
||||||
in the copied columns in the new table having type-specific default
|
in the copied columns in the new table having type-specific default
|
||||||
settings. For more on <literal>STORAGE</> settings, see
|
settings. For more on <literal>STORAGE</> settings, see
|
||||||
@ -356,24 +363,26 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
|
|||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Comments for the copied columns, constraints, and indexes
|
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
|
is specified. The default behavior is to exclude comments, resulting in
|
||||||
the copied columns and constraints in the new table having no comments.
|
the copied columns and constraints in the new table having no comments.
|
||||||
</para>
|
</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>.
|
<literal>INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES INCLUDING STORAGE INCLUDING COMMENTS</literal>.
|
||||||
</para>
|
</para>
|
||||||
<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
|
constraints copied by <literal>LIKE</> are not merged with similarly
|
||||||
named columns and constraints.
|
named columns and constraints.
|
||||||
If the same name is specified explicitly or in another
|
If the same name is specified explicitly or in another
|
||||||
<literal>LIKE</literal> clause, an error is signaled.
|
<literal>LIKE</literal> clause, an error is signaled.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The <literal>LIKE</literal> clause can also be used to copy columns from
|
The <literal>LIKE</literal> clause can also be used to copy column
|
||||||
views, foreign tables, or composite types. Inapplicable options (e.g., <literal>INCLUDING
|
definitions from views, foreign tables, or composite types.
|
||||||
INDEXES</literal> from a view) are ignored.
|
Inapplicable options (e.g., <literal>INCLUDING INDEXES</literal> from
|
||||||
|
a view) are ignored.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@ -1486,6 +1495,17 @@ CREATE TABLE employees OF employee_type (
|
|||||||
</para>
|
</para>
|
||||||
</refsect2>
|
</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>
|
<refsect2>
|
||||||
<title><literal>WITH</> Clause</title>
|
<title><literal>WITH</> Clause</title>
|
||||||
|
|
||||||
|
@ -1094,7 +1094,9 @@ generateClonedIndexStmt(CreateStmtContext *cxt, Relation source_idx,
|
|||||||
|
|
||||||
/*
|
/*
|
||||||
* We don't try to preserve the name of the source index; instead, just
|
* 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;
|
index->idxname = NULL;
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user