Re: rename constraint behavior for duplicate names?

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?

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