Ryan Bradetich <rbrad@hpb50023.boi.hp.com> writes:
>>>> Yes, it'd be nice to think about fixing up primary-key implicit indexes
>>>> while we are at it --- they have some of the same problems as SERIAL ...
> I'm not following this... When a table is dropped, all the indexes for
> that table get dropped. The indexes are associated with a table,
> whereas the sequences are just sequences not associated with a table.
> Am I understanding the issue correctly?
It's mainly a pg_dump issue: can pg_dump identify such an index as
having come from a PRIMARY KEY spec rather than a separate CREATE INDEX
command? This goes back to the complaint about pg_dump not being able
to fully reconstruct the logical connections in a database.
A related issue is inheritance: if I say PRIMARY KEY in the definition
of a table, and then make a child table that inherits from that table,
I'd expect the child's field to act like a PRIMARY KEY too --- in other
words it should have a unique index created for it. Right now I don't
believe that that happens.
What it all comes down to is that mapping these structures into "lower
level" objects without remembering the higher-level structure isn't
fully satisfactory. We need an explicit, persistent representation of
the PRIMARY KEY attribute. In that way it's the same problem as SERIAL.
The best solutions might be different, however.
regards, tom lane
