Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
Date
Msg-id CAKFQuwZV6gGB35c8VmL9ZL46ucupenvpVhgRgs2KmkW1p2yx9w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Dec 14, 2022 at 9:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> 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.

OK, that was me tunnel-visioned on the "index_parameters" syntax section where INCLUDE, etc... are listed and not seeing it there.

So, don't document that PRIMARY KEY accepts the NULLS [NOT] DISTINCT but make it do so anyway?

David J.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
Next
From: PG Bug reporting form
Date:
Subject: BUG #17721: A completely unused CTE negatively affect Query Plan