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

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.