Re: Two constraints with the same name not always allowed

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Two constraints with the same name not always allowed
Дата
Msg-id 13718.1535912142@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Two constraints with the same name not always allowed  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Two constraints with the same name not always allowed
Список 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


В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Two constraints with the same name not always allowed
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query