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.
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 ...' |