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