On Mon, 10 Apr 2006, Tom Lane wrote:
> Kris Jurka <books@ejurka.com> 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
