Re: rename constraint behavior for duplicate names? - Mailing list pgsql-hackers

From Allan Wang
Subject Re: rename constraint behavior for duplicate names?
Date
Msg-id 1125611540.15631.13.camel@localhost
Whole thread Raw
In response to Re: rename constraint behavior for duplicate names?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: rename constraint behavior for duplicate names?
List pgsql-hackers
On Thu, 2005-09-01 at 17:16 -0400, Tom Lane wrote:
> Allan Wang <allanvv@gmail.com> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Using multi-locale support in glibc
Next
From: Tom Lane
Date:
Subject: Re: rename constraint behavior for duplicate names?