On Thu, 2005-09-01 at 17:55 -0400, Tom Lane wrote:
> Allan Wang <[EMAIL PROTECTED]> writes:
> > 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
Allan Wang <[EMAIL PROTECTED]> writes:
> (It would still be used for suppressing the not-exists error)
Right, which is why RemoveRelConstraints has to tell if it removed
anything. The API could be changed, but not to "returns void".
regards, tom lane
Allan Wang <[EMAIL PROTECTED]> writes:
> 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
On Thu, 2005-09-01 at 17:16 -0400, Tom Lane wrote:
> Allan Wang <[EMAIL PROTECTED]> 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
> > d
Allan Wang <[EMAIL PROTECTED]> 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
