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.