There was some discussion last week on -bugs about how renaming an index
that belongs to a unique or primary key constraint is allowed, but can
lead to situations that can't be dumped/restored properly. This isn't
really pg_dump's fault, IMHO. We should rather make the backend enforce
that the index's name stays in sync with the constraint's name. (Well,
I guess we could imagine making pg_dump deal with this by issuing
ALTER TABLE ADD CONSTRAINT and then ALTER INDEX RENAME, but ... ick.)
There seem to be three things we could do:
1. Make ALTER INDEX RENAME fail if the index belongs to a constraint.
This is trivial code-wise, but doesn't seem especially helpful to users.
2. Make ALTER INDEX RENAME automatically rename the constraint, too.
This would take a few dozen lines of code but is certainly not hard.
3. Invent an ALTER TABLE RENAME CONSTRAINT command, and have it also
rename the underlying index. This would take more code than would be
reasonable to add to 8.3 at this late date, I think, but it would
add more functionality since you could also rename constraints of
other types.
Now, doing either #1 or #2 today would not foreclose doing #3 later
(actually, we *must* do either #1 or #2 together with #3 in order to
meet the goal of not letting the names diverge).
I'm thinking about doing #2 for 8.3 and leaving #3 as a TODO item.
Comments?
regards, tom lane