From: Tom Lane Date: Wed, 8 Sep 2004 20:47:37 +0000 (+0000) Subject: Clarify description of SET CONSTRAINTS. Point out that it is still X-Git-Tag: REL8_0_0BETA3~124 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b1c4bdae74dbfccac36feb05f9511fe02bdc289a;p=postgresql Clarify description of SET CONSTRAINTS. Point out that it is still missing the ability to schema-qualify constraint names. --- diff --git a/doc/src/sgml/ref/set_constraints.sgml b/doc/src/sgml/ref/set_constraints.sgml index 47aa46da6f..0c976c93e2 100644 --- a/doc/src/sgml/ref/set_constraints.sgml +++ b/doc/src/sgml/ref/set_constraints.sgml @@ -1,4 +1,4 @@ - + SET CONSTRAINTS @@ -7,7 +7,7 @@ SET CONSTRAINTS - set the constraint mode of the current transaction + set constraint checking modes for the current transaction @@ -25,28 +25,40 @@ SET CONSTRAINTS { ALL | name [, ... SET CONSTRAINTS sets the behavior of constraint - evaluation in the current transaction. In - IMMEDIATE mode, constraints are checked at the - end of each statement. In DEFERRED mode, - constraints are not checked until transaction commit. + checking within the current transaction. IMMEDIATE + constraints are checked at the end of each + statement. DEFERRED constraints are not checked until + transaction commit. Each constraint has its own + IMMEDIATE or DEFERRED mode. - When you change the mode of a constraint to be - IMMEDIATE, the new constraint mode takes effect - retroactively: any outstanding data modifications that would have - been checked at the end of the transaction (when using - DEFERRED) are instead checked during the - execution of the SET CONSTRAINTS command. - - - - Upon creation, a constraint is always give one of three + Upon creation, a constraint is given one of three characteristics: INITIALLY DEFERRED, INITIALLY IMMEDIATE DEFERRABLE, or INITIALLY IMMEDIATE NOT DEFERRABLE. The third class is not affected by the SET CONSTRAINTS - command. + command. The first two classes start every transaction in the + indicated mode, but their behavior can be changed within a transaction + by SET CONSTRAINTS. + + + + SET CONSTRAINTS with a list of constraint names changes + the mode of just those constraints (which must all be deferrable). If + there are multiple constraints matching any given name, all are affected. + SET CONSTRAINTS ALL changes the mode of all deferrable + constraints. + + + + When you change the mode of a constraint from DEFERRED + to IMMEDIATE, the new mode takes effect + retroactively: any outstanding data modifications that would have + been checked at the end of the transaction are instead checked during the + execution of the SET CONSTRAINTS command. + If any such constraint is violated, the SET CONSTRAINTS + fails (and does not change the constraint mode). @@ -81,6 +93,14 @@ SET CONSTRAINTS { ALL | name [, ... PostgreSQL, it only applies to foreign-key constraints. + + + The SQL standard says that constraint names appearing in SET + CONSTRAINTS can be schema-qualified. This is not yet + supported by PostgreSQL: the names must + be unqualified, and all constraints matching the command will be + affected no matter which schema they are in. +