From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Renaming a constraint's index |
Date: | 2008-01-17 20:02:38 |
Message-ID: | 023A056E-41D5-4487-970E-074E98D2A9DA@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2008-01-17 20:13:24 | Re: proposal for 8.4: PL/pgSQL - statement CASE |
Previous Message | Decibel! | 2008-01-17 19:53:13 | Re: Thick indexes - a look at count(1) query |