Обсуждение: schema-qualified SET CONSTRAINTS
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. Kris Jurka
Вложения
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
Based on discussion, it seems the idea of using search path seems accepted. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --------------------------------------------------------------------------- Kris Jurka wrote: > > 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. > > Kris Jurka Content-Description: [ Attachment, skipping... ] -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Patch applied. Thanks. I also updated our SGML documentation: The current schema search path is used to find the first matching name if no schema name is specified. --------------------------------------------------------------------------- Kris Jurka wrote: > > 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. > > Kris Jurka Content-Description: [ Attachment, skipping... ] -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +