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?
|
Список | 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 по дате отправления: