1- <!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.10 2003/11/29 19:51:39 pgsql Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.11 2004/09/08 20:47:37 tgl Exp $ -->
22<refentry id="SQL-SET-CONSTRAINTS">
33 <refmeta>
44 <refentrytitle id="SQL-SET-CONSTRAINTS-title">SET CONSTRAINTS</refentrytitle>
77
88 <refnamediv>
99 <refname>SET CONSTRAINTS</refname>
10- <refpurpose>setthe constraintmode of the current transaction</refpurpose>
10+ <refpurpose>set constraintchecking modes for the current transaction</refpurpose>
1111 </refnamediv>
1212
1313 <indexterm zone="sql-set-constraints">
@@ -25,28 +25,40 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
2525
2626 <para>
2727 <command>SET CONSTRAINTS</command> sets the behavior of constraint
28- evaluation in the current transaction. In
29- <literal>IMMEDIATE</literal> mode, constraints are checked at the
30- end of each statement. In <literal>DEFERRED</literal> mode,
31- constraints are not checked until transaction commit.
28+ checking within the current transaction. <literal>IMMEDIATE</literal>
29+ constraints are checked at the end of each
30+ statement. <literal>DEFERRED</literal> constraints are not checked until
31+ transaction commit. Each constraint has its own
32+ <literal>IMMEDIATE</literal> or <literal>DEFERRED</literal> mode.
3233 </para>
3334
3435 <para>
35- When you change the mode of a constraint to be
36- <literal>IMMEDIATE</literal>, the new constraint mode takes effect
37- retroactively: any outstanding data modifications that would have
38- been checked at the end of the transaction (when using
39- <literal>DEFERRED</literal>) are instead checked during the
40- execution of the <command>SET CONSTRAINTS</command> command.
41- </para>
42-
43- <para>
44- Upon creation, a constraint is always give one of three
36+ Upon creation, a constraint is given one of three
4537 characteristics: <literal>INITIALLY DEFERRED</literal>,
4638 <literal>INITIALLY IMMEDIATE DEFERRABLE</literal>, or
4739 <literal>INITIALLY IMMEDIATE NOT DEFERRABLE</literal>. The third
4840 class is not affected by the <command>SET CONSTRAINTS</command>
49- command.
41+ command. The first two classes start every transaction in the
42+ indicated mode, but their behavior can be changed within a transaction
43+ by <command>SET CONSTRAINTS</command>.
44+ </para>
45+
46+ <para>
47+ <command>SET CONSTRAINTS</command> with a list of constraint names changes
48+ the mode of just those constraints (which must all be deferrable). If
49+ there are multiple constraints matching any given name, all are affected.
50+ <command>SET CONSTRAINTS ALL</command> changes the mode of all deferrable
51+ constraints.
52+ </para>
53+
54+ <para>
55+ When you change the mode of a constraint from <literal>DEFERRED</literal>
56+ to <literal>IMMEDIATE</literal>, the new mode takes effect
57+ retroactively: any outstanding data modifications that would have
58+ been checked at the end of the transaction are instead checked during the
59+ execution of the <command>SET CONSTRAINTS</command> command.
60+ If any such constraint is violated, the <command>SET CONSTRAINTS</command>
61+ fails (and does not change the constraint mode).
5062 </para>
5163
5264 <para>
@@ -81,6 +93,14 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
8193 <productname>PostgreSQL</productname>, it only applies to
8294 foreign-key constraints.
8395 </para>
96+
97+ <para>
98+ The SQL standard says that constraint names appearing in <command>SET
99+ CONSTRAINTS</command> can be schema-qualified. This is not yet
100+ supported by <productname>PostgreSQL</productname>: the names must
101+ be unqualified, and all constraints matching the command will be
102+ affected no matter which schema they are in.
103+ </para>
84104 </refsect1>
85105</refentry>
86106