public inbox for [email protected]  
help / color / mirror / Atom feed
CREATE TABLE LIKE, regarding constraints
5+ messages / 3 participants
[nested] [flat]

* CREATE TABLE LIKE, regarding constraints
@ 2011-12-30 21:27  [email protected]
  0 siblings, 1 reply; 5+ messages in thread

From: [email protected] @ 2011-12-30 21:27 UTC (permalink / raw)
  To: pgsql-docs

www.postgresql.org/docs/9.0/static/sql-createtable.html
== == == == ==
LIKE parent_table [ like_option ... ]
. . .
Not-null constraints are always copied to the new table.
CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied.
. . .
== == == == ==

But I do see PK and UNIQUE constraints
  CONSTRAINT blah_pkey PRIMARY KEY (id),
  CONSTRAINT blah_host_id_key UNIQUE (host_id)
in the def of the new table.


Also, why is there no discussion of what "EXCLUDING CONSTRAINTS" will result in ?

Thanks,
-dvs-





^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: CREATE TABLE LIKE, regarding constraints
@ 2011-12-31 12:42  Magnus Hagander <[email protected]>
  parent: [email protected]
  0 siblings, 1 reply; 5+ messages in thread

From: Magnus Hagander @ 2011-12-31 12:42 UTC (permalink / raw)
  To: [email protected]; +Cc: pgsql-docs

On Fri, Dec 30, 2011 at 22:27,  <[email protected]> wrote:
> www.postgresql.org/docs/9.0/static/sql-createtable.html
> == == == == ==
> LIKE parent_table [ like_option ... ]
> . . .
> Not-null constraints are always copied to the new table.
> CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied.
> . . .
> == == == == ==
>
> But I do see PK and UNIQUE constraints
>  CONSTRAINT blah_pkey PRIMARY KEY (id),
>  CONSTRAINT blah_host_id_key UNIQUE (host_id)
> in the def of the new table.

Can you provide the commands you ran to make that happen? It doesn't
happen for me in a trivial test.


> Also, why is there no discussion of what "EXCLUDING CONSTRAINTS" will result in ?



-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: CREATE TABLE LIKE, regarding constraints
@ 2012-01-02 14:32  [email protected]
  parent: Magnus Hagander <[email protected]>
  0 siblings, 1 reply; 5+ messages in thread

From: [email protected] @ 2012-01-02 14:32 UTC (permalink / raw)
  To: [email protected]; +Cc: pgsql-docs

-----Original Message-----
From: Magnus Hagander [mailto:[email protected]] 
Sent: Saturday, December 31, 2011 7:42 AM
To: Sahagian, David
Cc: [email protected]
Subject: Re: [DOCS] CREATE TABLE LIKE, regarding constraints

On Fri, Dec 30, 2011 at 22:27,  <[email protected]> wrote:
> www.postgresql.org/docs/9.0/static/sql-createtable.html
> == == == == ==
> LIKE parent_table [ like_option ... ]
> . . .
> Not-null constraints are always copied to the new table.
> CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied.
> . . .
> == == == == ==
>
> But I do see PK and UNIQUE constraints
>  CONSTRAINT blah_pkey PRIMARY KEY (id),
>  CONSTRAINT blah_host_id_key UNIQUE (host_id)
> in the def of the new table.

Can you provide the commands you ran to make that happen? It doesn't
happen for me in a trivial test.

> Also, why is there no discussion of what "EXCLUDING CONSTRAINTS" will result in ?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Magnus, 
I did some more "testing" of CREATE TABLE LIKE, 
and now see that [INCLUDING INDEXES] also can cause PRIMARY KEY and UNIQUE constraints to become part of the new table.

++++++++++++++
 CREATE TABLE yesConstr_noIndex_tbl (
   like mytbl 
   INCLUDING DEFAULTS  INCLUDING CONSTRAINTS                     INCLUDING STORAGE 
 );
++++++++++++++
  no PRIMARY KEY
  no UNIQUE
  no indexes

++++++++++++++
 CREATE TABLE  noConstr_yesIndex_tbl (
   like mytbl 
   INCLUDING DEFAULTS                        INCLUDING INDEXES   INCLUDING STORAGE 
 );
++++++++++++++
  NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "mytbl_pkey"           for table "mytbl"
  NOTICE:  CREATE TABLE / UNIQUE      will create implicit index "mytbl_host_id_key"    for table "mytbl"

  CONSTRAINT mytbl_pkey PRIMARY KEY (id),
  CONSTRAINT mytbl_host_id_key UNIQUE (host_id)
  and 2 unrelated indexes: (a_diff_col) (yet_a_diff_col)


I have no problem with this behavior, 
but the doc probably deserves some clarification on the "relationship" between 
[INCLUDING CONSTRAINTS] and [INCLUDING INDEXES].

Thanks,
-dvs-






^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: CREATE TABLE LIKE, regarding constraints
@ 2012-01-02 19:31  Magnus Hagander <[email protected]>
  parent: [email protected]
  0 siblings, 1 reply; 5+ messages in thread

From: Magnus Hagander @ 2012-01-02 19:31 UTC (permalink / raw)
  To: [email protected]; +Cc: pgsql-docs

On Mon, Jan 2, 2012 at 15:32,  <[email protected]> wrote:
> On Fri, Dec 30, 2011 at 22:27,  <[email protected]> wrote:
>> www.postgresql.org/docs/9.0/static/sql-createtable.html
>> == == == == ==
>> LIKE parent_table [ like_option ... ]
>> . . .
>> Not-null constraints are always copied to the new table.
>> CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied.
>> . . .
>> == == == == ==
>>
>> But I do see PK and UNIQUE constraints
>>  CONSTRAINT blah_pkey PRIMARY KEY (id),
>>  CONSTRAINT blah_host_id_key UNIQUE (host_id)
>> in the def of the new table.
>
> Can you provide the commands you ran to make that happen? It doesn't
> happen for me in a trivial test.
>
>> Also, why is there no discussion of what "EXCLUDING CONSTRAINTS" will result in ?
>
>
> Magnus,
> I did some more "testing" of CREATE TABLE LIKE,
> and now see that [INCLUDING INDEXES] also can cause PRIMARY KEY and UNIQUE constraints to become part of the new table.

Ah, that explains why I couldn't reproduce it.


> I have no problem with this behavior,
> but the doc probably deserves some clarification on the "relationship" between
> [INCLUDING CONSTRAINTS] and [INCLUDING INDEXES].

That might be a good idea, yes. Feel like cooking up a patch?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: CREATE TABLE LIKE, regarding constraints
@ 2012-08-26 20:35  Bruce Momjian <[email protected]>
  parent: Magnus Hagander <[email protected]>
  0 siblings, 0 replies; 5+ messages in thread

From: Bruce Momjian @ 2012-08-26 20:35 UTC (permalink / raw)
  To: Magnus Hagander <[email protected]>; +Cc: [email protected]; pgsql-docs

On Mon, Jan  2, 2012 at 08:31:43PM +0100, Magnus Hagander wrote:
> On Mon, Jan 2, 2012 at 15:32,  <[email protected]> wrote:
> > On Fri, Dec 30, 2011 at 22:27,  <[email protected]> wrote:
> >> www.postgresql.org/docs/9.0/static/sql-createtable.html
> >> == == == == ==
> >> LIKE parent_table [ like_option ... ]
> >> . . .
> >> Not-null constraints are always copied to the new table.
> >> CHECK constraints will only be copied if INCLUDING CONSTRAINTS is specified; other types of constraints will never be copied.
> >> . . .
> >> == == == == ==
> >>
> >> But I do see PK and UNIQUE constraints
> >>  CONSTRAINT blah_pkey PRIMARY KEY (id),
> >>  CONSTRAINT blah_host_id_key UNIQUE (host_id)
> >> in the def of the new table.
> >
> > Can you provide the commands you ran to make that happen? It doesn't
> > happen for me in a trivial test.
> >
> >> Also, why is there no discussion of what "EXCLUDING CONSTRAINTS" will result in ?
> >
> >
> > Magnus,
> > I did some more "testing" of CREATE TABLE LIKE,
> > and now see that [INCLUDING INDEXES] also can cause PRIMARY KEY and UNIQUE constraints to become part of the new table.
> 
> Ah, that explains why I couldn't reproduce it.
> 
> 
> > I have no problem with this behavior,
> > but the doc probably deserves some clarification on the "relationship" between
> > [INCLUDING CONSTRAINTS] and [INCLUDING INDEXES].
> 
> That might be a good idea, yes. Feel like cooking up a patch?

I have applied the attached patch based on this report.  

It is confusing that INCLUDING CONSTRAINTS only copies CHECK
constraints, and INCLUDING INDEXES is required for PRIMARY KEY and
UNIQUE constraints.  Is there a reason our logic is so odd here?  The
SQL standard?

-- 
  Bruce Momjian  <[email protected]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


Attachments:

  [text/x-diff] constraints.diff (1.8K, 2-constraints.diff)
  download | inline diff:
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
new file mode 100644
index 19e6f8e..445ca40
*** a/doc/src/sgml/ref/create_table.sgml
--- b/doc/src/sgml/ref/create_table.sgml
*************** CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY
*** 336,351 ****
       </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.
!      </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.
       </para>
       <para><literal>STORAGE</> settings for the copied column definitions will only
        be copied if <literal>INCLUDING STORAGE</literal> is specified.  The
--- 336,348 ----
       </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


^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2012-08-26 20:35 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-12-30 21:27 CREATE TABLE LIKE, regarding constraints [email protected]
2011-12-31 12:42 ` Magnus Hagander <[email protected]>
2012-01-02 14:32   ` [email protected]
2012-01-02 19:31     ` Magnus Hagander <[email protected]>
2012-08-26 20:35       ` Bruce Momjian <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox