| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| 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:08:16 |
| Message-ID: | 2688007.1671034096@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2022-12-14 16:34:11 | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
| Previous Message | David G. Johnston | 2022-12-14 15:59:26 | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |