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

> On 16 Dec 2022, at 09:07, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>
> On 15.12.22 00:27, Tom Lane wrote:
>> Daniel Gustafsson <daniel(at)yesql(dot)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.
>> I'll defer to Peter on whether this is in fact the right way to go,
>> or we should relax the syntax restriction as David suggests.
>
> My first instinct was to just fix pg_dump to not dump syntax that can't be loaded in.
>
> It shouldn't matter what null treatment the underlying unique index has, since the primary key can't have nulls anyway, so either type of index should be acceptable. But then we'd need to think through a bunch of possible ALTER behaviors. For example, if we just change pg_dump and leave the index as is, a subsequent dump and restore would lose the original null treatment flag. What if someone then wants to re-detach the constraint from the index? (Does that exist now? Maybe not, but it could.) What should happen then? This could all be worked out, I think, but it would need more thought.
>
> In short, I think preventing the ALTER command, as proposed in this patch, seems like a good solution for the moment. Additional work to enable some of this could follow later independently.

The attached removes the change from pg_dump and only prohibits the ALTER TABLE
command for attaching the index. Since it will render dumps unable to be
restored I also added a check to pg_upgrade to cover the case.

--
Daniel Gustafsson https://vmware.com/