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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, "zedaardv(at)drizzle(dot)com" <zedaardv(at)drizzle(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
Date: 2022-12-14 16:34:11
Message-ID: CAKFQuwZV6gGB35c8VmL9ZL46ucupenvpVhgRgs2KmkW1p2yx9w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Dec 14, 2022 at 9:08 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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.

In response to

Browse pgsql-bugs by date

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