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 ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate