Re: Two constraints with the same name not always allowed

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>, André Hänsel <andre@webkr.de>, pgsql-bugs@postgresql.org
Date: 2018-09-06T22:07:51Z
Lists: pgsql-bugs
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 02/09/2018 19:00, Tom Lane wrote:
>> This also points up the lack of a suitable unique index on pg_constraint.
>> It's sort of difficult to figure out what that should look like given that
>> pg_constraint contains two quasi-independent collections of constraints,
>> but maybe UNIQUE(conrelid,contypid,conname) would serve given the
>> reasonable assumption that exactly one of conrelid and contypid is zero.

> Sketches for assertions set both conrelid and contypid to zero.  I think
> the unique constraint would have to include connamespace to support that
> properly.

Well, as I said in the commit message, I'm now of the opinion that
assertions should go in some new catalog.  It was a mistake to put
domain and relation constraints into the same catalog, and I don't
think we ought to double down on that mistake by confusing the
question of "what's this catalog's primary key?" still more.

But yes, *if* we bull ahead and do it the wrong way, that would be
a necessary change.  I don't like it much, because it would fuzz up
the question of whether the unique index actually guarantees only
one instance of a constraint name per relid or typid.

			regards, tom lane


Commits

  1. Fully enforce uniqueness of constraint names.