Tom Lane wrote:
> 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?
>
>
>
+1
cheers
andrew
