On Mon, 10 Apr 2006, Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
The attached patch allows SET CONSTRAINTS to take a schema qualified
constraint name (myschema.t1_fk_t2) and when given a bare constraint name
it uses the search_path to determine the matching constraint instead of
the previous behavior of disabling all identically named constraints.
This patch seems egregiously non backwards compatible :-(.
Yes, it does change the existing behavior, but "egregiously"? How many
applications intentionally defer constraints in multiple schemas at once?
Not many. I would guess the more likely situation is that these
applications don't even realize that they are deferring more than one
constraint when it happens. So there will be some very minor pain when
they must select the desired constraint (if it doesn't happen already by
search_path) or explicitly defer more than one constraint, but I'm OK
with that. The existing behavior of SET CONSTRAINTS affecting everything
is not what a user would expect when we have tools like search_path
available.
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
