Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
От | Vik Fearing |
---|---|
Тема | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' |
Дата | |
Msg-id | 9344998b-e9aa-fdd8-9a7e-3f17811599fa@postgresfriends.org обсуждение исходный текст |
Ответ на | Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...' (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: BUG #17720: pg_dump creates a dump with primary key that cannot be restored, when specifying 'using index ...'
|
Список | pgsql-bugs |
On 12/15/22 14:18, Daniel Gustafsson wrote: >> On 15 Dec 2022, at 00:27, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Daniel Gustafsson <daniel@yesql.se> writes: >>> The attached prohibits the use of NULLS NOT DISTINCT for backing primary key >>> constraints but allow them for unique constraints. Is this along the lines of >>> what you had in mind? >> >> Needs more than zero comments in the code, and why bother testing >> is_alter_table in index_check_primary_key? We're disallowing >> this case across-the-board, no matter how you get to it. > > That was an, admittedly poor, attempt at self-documenting code. Removed and > comments added in the attached. [reviewing patch...] If the point in adding a primary key USING INDEX is to avoid building an index, then this restriction defeats that purpose. We have no ALTER INDEX command to switch or drop the <unique null treatment>. Since the primary key can't have any nulls anyway, I think we should just flip this, perhaps with a NOTICE like the rename does. -- Vik Fearing
В списке pgsql-bugs по дате отправления: