Dean Rasheed <dean.a.rash...@googlemail.com> writes:
> Agreed. That's much neater. However, it does introduce a change in
> behaviour - if you have 2 constraints with the same name in different
> schemas, one deferrable, and one not, and the non-deferrable one is
> first on the search path, then you'll get an error if you try to defer
> the other one, referring to it with an unqualified name. This used to
> work, when it was searching for the trigger first.
> So perhaps the code should continue searching after finding a
> non-deferrable constraint, remembering the fact that it found one, and
> only report the error at the end if it didn't also find a deferrable
> one.
I went around on that a few times before committing. It's not really
true that it used to work, at least not for cases where the
nondeferrable constraint was also an FK constraint; that threw an error
just as now. What we've done is opened up the search so that it will
find nondeferrable index constraints, which is more or less the whole
point of Hubert's request.
The part that I actually think is weird is that the search stops after
the first schema in which it finds any matches. If we removed that then
we could just document the behavior as "sets the constraint mode for all
matching constraint names", full stop. Which definitely seems easier
to understand than what we have now. (The SQL spec is no big help here
btw, it just says "if a <constraint name> is specified, then it shall
identify a deferrable constraint". No clarity about what "identify"
means.)
The other point you bring up is whether to silently skip matching
constraints that aren't deferrable, rather than throwing error.
I'm not real excited about that --- it seems likely to mask problems,
and to the extent that you want to put faith in the wording of the SQL
spec here, it seems clear that an error is what they want.
These are certainly easy enough changes from a code standpoint.
The question is what behavior makes the most sense. Comments anyone?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
