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 :-(. A behavior
that would be backwards compatible is to retain the previous behavior
given an un-qualified name, while if given a schema-qualified name,
modify all matching constraints within that schema. That doesn't seem
very self-consistent though. A compromise that might succeed in making
*everybody* unhappy would be for the unqualified-name case to only
affect constraints that are visible in the current search path (but
affect all of them, not only one as in this patch).
Given the fundamental point that we don't insist on uniqueness of
constraint names within schemas, I'm not sure that the spec gives us
any useful guidance on what SET CONSTRAINTS should affect.
Anyway, I'm not sure what to do, but I am sure it requires some
discussion not just a patch.
regards, tom lane