On Jan 16, 2008, at 5:20 PM, 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.
+1. IMO, the constraint should be the canonical source of the name,
not the other way around.
> 2. Make ALTER INDEX RENAME automatically rename the constraint, too.
> This would take a few dozen lines of code but is certainly not hard.
-1 (see above)
> 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.
+1
> 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?
Like I said, I don't think it makes sense for the index to drive
constraint names.
If someone *really* needed to do this in 8.3, could they accomplish
it by updating the catalog tables? I'd rather wait for 8.4 than put
#2 in...
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
