Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 90A3F1715CA for ; Mon, 2 Jan 2012 15:31:58 -0400 (AST) Received: from mail-yw0-f46.google.com ([209.85.213.46]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rhnbw-0005FH-Qg for pgsql-docs@postgresql.org; Mon, 02 Jan 2012 19:31:58 +0000 Received: by yhr47 with SMTP id 47so9189000yhr.19 for ; Mon, 02 Jan 2012 11:31:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.128.138 with SMTP id f10mr65576511yhi.2.1325532703310; Mon, 02 Jan 2012 11:31:43 -0800 (PST) Received: by 10.100.4.17 with HTTP; Mon, 2 Jan 2012 11:31:43 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Jan 2012 20:31:43 +0100 Message-ID: Subject: Re: CREATE TABLE LIKE, regarding constraints From: Magnus Hagander To: david.sahagian@emc.com Cc: pgsql-docs@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201201/2 X-Sequence-Number: 7153 On Mon, Jan 2, 2012 at 15:32, wrote: > On Fri, Dec 30, 2011 at 22:27, =A0 wrote: >> www.postgresql.org/docs/9.0/static/sql-createtable.html >> =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D >> 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 specif= ied; other types of constraints will never be copied. >> . . . >> =3D=3D =3D=3D =3D=3D =3D=3D =3D=3D >> >> But I do see PK and UNIQUE constraints >> =A0CONSTRAINT blah_pkey PRIMARY KEY (id), >> =A0CONSTRAINT 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 re= sult in ? > > > Magnus, > I did some more "testing" of CREATE TABLE LIKE, > and now see that [INCLUDING INDEXES] also can cause PRIMARY KEY and UNIQU= E 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" be= tween > [INCLUDING CONSTRAINTS] and [INCLUDING INDEXES]. That might be a good idea, yes. Feel like cooking up a patch? --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/