Re: [HACKERS] rename constraint behavior for duplicate names?
On Thu, 2005-09-01 at 17:55 -0400, Tom Lane wrote: > Allan Wang <[EMAIL PROTECTED]> writes: > > Alright, I see why the checks are still needed. The unique index should > > be on relname, conname right? Also looking into DROP CONSTRAINT's code, > > it gives a notice about "multiple constraint names dropped" when > > RemoveRelConstraints(rel, conname) returns > 1. This check isn't needed > > anymore right? Also RemoveRelConstraints can be simplified to assume > > only one row will need removing, and be turned into a void function? > > Not unless you want to break the "quiet" option for ATExecDropConstraint. Is the quiet option supposed to work anyway other than suppressing the not exists error? Since there can't be multiple constraint names the notice is never executed anyway. Otherwise I don't see how it would break. (It would still be used for suppressing the not-exists error) Allan Wang ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] rename constraint behavior for duplicate names?
Allan Wang <[EMAIL PROTECTED]> writes: > (It would still be used for suppressing the not-exists error) Right, which is why RemoveRelConstraints has to tell if it removed anything. The API could be changed, but not to "returns void". regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] rename constraint behavior for duplicate names?
Allan Wang <[EMAIL PROTECTED]> writes: > Alright, I see why the checks are still needed. The unique index should > be on relname, conname right? Also looking into DROP CONSTRAINT's code, > it gives a notice about "multiple constraint names dropped" when > RemoveRelConstraints(rel, conname) returns > 1. This check isn't needed > anymore right? Also RemoveRelConstraints can be simplified to assume > only one row will need removing, and be turned into a void function? Not unless you want to break the "quiet" option for ATExecDropConstraint. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] rename constraint behavior for duplicate names?
On Thu, 2005-09-01 at 17:16 -0400, Tom Lane wrote: > Allan Wang <[EMAIL PROTECTED]> writes: > > I've been looking through the code from CommentConstraint > > and ATExecDropConstraint and they error out on duplicate constraint > > names for a relation. However, ADD CONSTRAINT's code checks for > > duplicates and errors out, so would the stuff in comment/drop be useless > > checks then? And I would not have to worry about duplicate constraint > > names for my rename code? > > Note however that it's customary to check for duplication and > issue a specific error message for it --- "unique key violation" isn't > considered a friendly error message. The index should just serve as a > backstop in case of race conditions or other unforeseen problems. Alright, I see why the checks are still needed. The unique index should be on relname, conname right? Also looking into DROP CONSTRAINT's code, it gives a notice about "multiple constraint names dropped" when RemoveRelConstraints(rel, conname) returns > 1. This check isn't needed anymore right? Also RemoveRelConstraints can be simplified to assume only one row will need removing, and be turned into a void function? Allan Wang ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] rename constraint behavior for duplicate names?
Allan Wang <[EMAIL PROTECTED]> writes: > I've been looking through the code from CommentConstraint > and ATExecDropConstraint and they error out on duplicate constraint > names for a relation. However, ADD CONSTRAINT's code checks for > duplicates and errors out, so would the stuff in comment/drop be useless > checks then? And I would not have to worry about duplicate constraint > names for my rename code? Hmm ... there seems to be a certain amount of version skew here. Awhile back (experimentation says it was up through 7.2) we would allow multiple foreign key constraints with the same name, and with a name duplicating a check constraint ... but not AFAICS duplicate check constraint names. I think these various bits of code probably need to be brought into agreement about what the plan is. If we are going to enforce constraint name uniqueness then there ought to be a unique index guaranteeing it (which in turn would allow simplification of the lookup code). Note however that it's customary to check for duplication and issue a specific error message for it --- "unique key violation" isn't considered a friendly error message. The index should just serve as a backstop in case of race conditions or other unforeseen problems. It strikes me BTW that having pg_constraint cover both table and domain constraints was probably a dumb idea, and that normalization principles would suggest splitting it into one table for each purpose. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
