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-02T18:15:42Z
Lists: pgsql-bugs
I wrote: > 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. Note that if you repeat that last command, what you get is regression=# ALTER TABLE t ADD CONSTRAINT foo UNIQUE(c); ERROR: relation "foo" already exists I think the code supposes that checking for duplicate relation name is sufficient; but of course it is not if we want a table's constraints to have distinct names, since they may not all correspond to indexes. I do not think we can back-patch a change here --- it might break databases that are working satisfactorily today. But it seems like we could tighten this up in HEAD and maybe v11. regards, tom lane
Commits
-
Fully enforce uniqueness of constraint names.
- fb466d7b5dbe 11.0 landed
- 17b7c302b5fc 12.0 landed