Re: rename constraint behavior for duplicate names?

Поиск
Список
Период
Сортировка
От Allan Wang
Тема Re: rename constraint behavior for duplicate names?
Дата
Msg-id 1125611540.15631.13.camel@localhost
обсуждение исходный текст
Ответ на Re: rename constraint behavior for duplicate names?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: rename constraint behavior for duplicate names?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, 2005-09-01 at 17:16 -0400, Tom Lane wrote:
> Allan Wang <allanvv@gmail.com> writes:
> > I've been looking through the code from CommentConstraint
> > and ATExecDropConstraint and they error out on duplicate constraint
> > names for a relation. However, ADD CONSTRAINT's code checks for
> > duplicates and errors out, so would the stuff in comment/drop be useless
> > checks then? And I would not have to worry about duplicate constraint
> > names for my rename code?
> 
> Note however that it's customary to check for duplication and
> issue a specific error message for it --- "unique key violation" isn't
> considered a friendly error message.  The index should just serve as a
> backstop in case of race conditions or other unforeseen problems.

Alright, I see why the checks are still needed. The unique index should
be on relname, conname right? Also looking into DROP CONSTRAINT's code,
it gives a notice about "multiple constraint names dropped" when
RemoveRelConstraints(rel, conname) returns > 1. This check isn't needed
anymore right? Also RemoveRelConstraints can be simplified to assume
only one row will need removing, and be turned into a void function?

Allan Wang



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Using multi-locale support in glibc
Следующее
От: Tom Lane
Дата:
Сообщение: Re: rename constraint behavior for duplicate names?