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: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: André Hänsel <andre@webkr.de>, pgsql-bugs@postgresql.org
Date: 2018-09-02T17:00:45Z
Lists: pgsql-bugs
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "André" == André Hänsel <andre@webkr.de> writes: > André> Case 2: > André> CREATE TABLE t(c integer); > André> ALTER TABLE t ADD CONSTRAINT foo CHECK(c > 1); > André> ALTER TABLE t ADD CONSTRAINT foo UNIQUE(c); > André> -> Creates two constraints, both called "foo". > I'd call _that_ a bug, myself - having two constraints on a table with > the same name potentially messes up a lot of automated maintenance > operations. Agreed. We must have missed a check for constraint-exists someplace. 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. Potentially we could drop pg_constraint_conrelid_index and pg_constraint_contypid_index, replacing scans on those with scans on this new unique index. regards, tom lane
Commits
-
Fully enforce uniqueness of constraint names.
- fb466d7b5dbe 11.0 landed
- 17b7c302b5fc 12.0 landed