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
-
Fully enforce uniqueness of constraint names.
- fb466d7b5dbe 11.0 landed
- 17b7c302b5fc 12.0 landed