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
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 |