Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5UJ3-0001Ek-Ms for pgsql-bugs@arkaria.postgresql.org; Wed, 14 Dec 2022 16:08:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1p5UJ2-00007Q-Ea for pgsql-bugs@arkaria.postgresql.org; Wed, 14 Dec 2022 16:08:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5UJ2-00007F-6a for pgsql-bugs@lists.postgresql.org; Wed, 14 Dec 2022 16:08:28 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5UIw-0002mk-04 for pgsql-bugs@lists.postgresql.org; Wed, 14 Dec 2022 16:08:27 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2BEG8GW02688008; Wed, 14 Dec 2022 11:08:16 -0500 From: Tom Lane To: "David G. Johnston" cc: Peter Eisentraut , Daniel Gustafsson , "zedaardv@drizzle.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' In-reply-to: References: <17720-dab8ee0fa85d316d@postgresql.org> <9C039DE3-EFBD-4D65-B4CF-90D8148B7B4C@yesql.se> <2684951.1671032222@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Wed, 14 Dec 2022 08:59:26 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2688006.1671034096.1@sss.pgh.pa.us> Date: Wed, 14 Dec 2022 11:08:16 -0500 Message-ID: <2688007.1671034096@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > I am thinking now that the failure to include NULLS [NOT] DISTINCT in the > CREATE TABLE syntax is an oversight that needs to be fixed. It just > doesn't make sense to have the two commands expose different features. It looks to me like it was pretty intentional, because both CREATE and ALTER TABLE let you write UNIQUE NULLS NOT DISTINCT but not PRIMARY KEY NULLS NOT DISTINCT. That doesn't seem like an oversight. regards, tom lane