Thread: TODO-Item: Rename of constraints
Hi
I propose the appended patch for the following TODO-items:
o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME
o Have ALTER INDEX update the name of a constraint using that index
o Add ALTER TABLE RENAME CONSTRAINT, update index name also
Joachim
Attachment
On Mon, 2005-12-05 at 10:24 +0100, Joachim Wieland wrote: > I propose the appended patch for the following TODO-items: > > o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME > o Have ALTER INDEX update the name of a constraint using that index > o Add ALTER TABLE RENAME CONSTRAINT, update index name also > Patch looks very interesting. I've read the additional docs you supply and agree with the thought processes therein. Not looked at detailed coding. Passes make check for me. My compiler complains: pg_constraint.c: In function ‘RenameConstraint’: pg_constraint.c:726: warning: ISO C90 forbids mixed declarations and code This probably allows you to rename an inherited constraint to another name. Not sure if that is a problem, but it probably ought to throw an error, but I'm not sure who would care. I'll test some more to see if my work on inherited constraints conflicts in any way. Patch applies (with some fuzz) alongside my inherited constraints patch. Best Regards, Simon Riggs
On Wed, Dec 07, 2005 at 09:54:44PM +0000, Simon Riggs wrote: > On Mon, 2005-12-05 at 10:24 +0100, Joachim Wieland wrote: > > o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME > > o Have ALTER INDEX update the name of a constraint using that index > > o Add ALTER TABLE RENAME CONSTRAINT, update index name also > My compiler complains: > pg_constraint.c: In function ???RenameConstraint???: > pg_constraint.c:726: warning: ISO C90 forbids mixed declarations and > code Sorry, that's some leftover from code rearrangements. I attach a new version of the patch, this time in the requested context-diff format which I forgot to create the other day. > This probably allows you to rename an inherited constraint to another > name. Not sure if that is a problem, but it probably ought to throw an > error, but I'm not sure who would care. I thought about that but since the constraint gets copied anyway and you have two (more or less) independent constraints afterwards I didn't see a reason why it should be forbidden to rename it. One could throw a warning at least but I don't remember many cases where postgresql issues a warning saying: "hey, what you're doing might be bad but I'll do it anyway". If the consensus on this one however is to forbid it or issue a warning at least, it would be no problem to detect this situation once your inherited constraint patch is in. > I'll test some more to see if my work on inherited constraints conflicts > in any way. Ok, thanks. Joachim
Attachment
Patch applied. Thanks. --------------------------------------------------------------------------- Joachim Wieland wrote: > On Wed, Dec 07, 2005 at 09:54:44PM +0000, Simon Riggs wrote: > > On Mon, 2005-12-05 at 10:24 +0100, Joachim Wieland wrote: > > > > o %Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME > > > o Have ALTER INDEX update the name of a constraint using that index > > > o Add ALTER TABLE RENAME CONSTRAINT, update index name also > > > > My compiler complains: > > pg_constraint.c: In function ???RenameConstraint???: > > pg_constraint.c:726: warning: ISO C90 forbids mixed declarations and > > code > > Sorry, that's some leftover from code rearrangements. I attach a new version > of the patch, this time in the requested context-diff format which I forgot > to create the other day. > > > > This probably allows you to rename an inherited constraint to another > > name. Not sure if that is a problem, but it probably ought to throw an > > error, but I'm not sure who would care. > > I thought about that but since the constraint gets copied anyway and you > have two (more or less) independent constraints afterwards I didn't see a > reason why it should be forbidden to rename it. One could throw a warning at > least but I don't remember many cases where postgresql issues a warning > saying: "hey, what you're doing might be bad but I'll do it anyway". If > the consensus on this one however is to forbid it or issue a warning at > least, it would be no problem to detect this situation once your inherited > constraint patch is in. > > > > I'll test some more to see if my work on inherited constraints conflicts > > in any way. > > Ok, thanks. > > > Joachim > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073