On Fri, 29 Jun 2018 08:39:01 +0200
Daniel Gustafsson <dan...@yesql.se> wrote:
> > On 29 Jun 2018, at 07:56, Yugo Nagata <nag...@sraoss.co.jp> wrote:
> > On Thu, 28 Jun 2018 16:22:15 -0700
> > "David G. Johnston" <david.g.johns...@gmail.com> wrote:
>
> >> ​Maybe try something like:
> >>
> >> It is legal to specify the same option multiple times - e.g., "INCLUDING
> >> option EXCLUDING option" - the outcome is whichever comes last in the
> >> command (i.e., in the example, option is excluded).
> >
> > Certainly. However, it seems to me that example is also redundant.
> > I rewrote this as follows:
> >
> > It is legal to specify multiple options for the same kind of object.
> > If they conflict, latter options always override former options.
> >
> > Does this make sense?
>
> I think this wording makes sense and is clear. Only found a small typo:
>
> + This is tipically used after <literal>INCLUDING ALL</literal>.
>
> s/tipically/typically/
Thanks a lot.
I updated the patch.
>
> cheers ./daniel
--
Yugo Nagata <nag...@sraoss.co.jp>
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 2a1eac9..6147d86 100644
--- a/doc/src/sgml/ref/create_table.sgml
+++ b/doc/src/sgml/ref/create_table.sgml
@@ -624,6 +624,13 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
<literal>INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING DEFAULTS INCLUDING IDENTITY INCLUDING INDEXES INCLUDING STATISTICS INCLUDING STORAGE</literal>.
</para>
<para>
+ If <literal>EXCLUDING</literal> option is specified after
+ <literal>INCLUDING</literal> option, the referenced objects are not copied.
+ This is typically used after <literal>INCLUDING ALL</literal>.
+ It is legal to specify multiple options for the same kind of object.
+ If they conflict, latter options always override former options.
+ </para>
+ <para>
Note that unlike <literal>INHERITS</literal>, columns and
constraints copied by <literal>LIKE</literal> are not merged with similarly
named columns and constraints.
