Re: Two constraints with the same name not always allowed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: André Hänsel <andre(at)webkr(dot)de>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Two constraints with the same name not always allowed
Date: 2018-09-02 18:15:42
Message-ID: 13718.1535912142@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>> "André" == André Hänsel <andre(at)webkr(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-09-02 18:55:20 Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Previous Message Tom Lane 2018-09-02 17:35:27 Re: Two constraints with the same name not always allowed