Re: rename constraint behavior for duplicate names?

On Thu, 2005-09-01 at 17:16 -0400, Tom Lane wrote:
> Allan Wang <allanvv(at)gmail(dot)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