Clarify description of SET CONSTRAINTS. Point out that it is still

missing the ability to schema-qualify constraint names.

doc/src/sgml/ref/set_constraints.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.10 2003/11/29 19:51:39 pgsql Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/set_constraints.sgml,v 1.11 2004/09/08 20:47:37 tgl Exp $ -->
 <refentry id="SQL-SET-CONSTRAINTS">
  <refmeta>
   <refentrytitle id="SQL-SET-CONSTRAINTS-title">SET CONSTRAINTS</refentrytitle>
@@ -7,7 +7,7 @@
 
  <refnamediv>
   <refname>SET CONSTRAINTS</refname>
-  <refpurpose>set the constraint mode of the current transaction</refpurpose>
+  <refpurpose>set constraint checking modes for the current transaction</refpurpose>
  </refnamediv>
 
  <indexterm zone="sql-set-constraints">
@@ -25,28 +25,40 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
 
   <para>
    <command>SET CONSTRAINTS</command> sets the behavior of constraint
-   evaluation in the current transaction. In
+   checking within the current transaction. <literal>IMMEDIATE</literal>
-   <literal>IMMEDIATE</literal> mode, constraints are checked at the
+   constraints are checked at the end of each
-   end of each statement. In <literal>DEFERRED</literal> mode,
+   statement. <literal>DEFERRED</literal> constraints are not checked until
-   constraints are not checked until transaction commit.
+   transaction commit.  Each constraint has its own
+   <literal>IMMEDIATE</literal> or <literal>DEFERRED</literal> mode.
   </para>
 
   <para>
-   When you change the mode of a constraint to be
+   Upon creation, a constraint is given one of three
-   <literal>IMMEDIATE</literal>, the new constraint mode takes effect
-   retroactively: any outstanding data modifications that would have
-   been checked at the end of the transaction (when using
-   <literal>DEFERRED</literal>) are instead checked during the
-   execution of the <command>SET CONSTRAINTS</command> command.
-  </para>
-
-  <para>
-   Upon creation, a constraint is always give one of three
    characteristics: <literal>INITIALLY DEFERRED</literal>,
    <literal>INITIALLY IMMEDIATE DEFERRABLE</literal>, or
    <literal>INITIALLY IMMEDIATE NOT DEFERRABLE</literal>. The third
    class is not affected by the <command>SET CONSTRAINTS</command>
-   command.
+   command.  The first two classes start every transaction in the
+   indicated mode, but their behavior can be changed within a transaction
+   by <command>SET CONSTRAINTS</command>.
+  </para>
+
+  <para>
+   <command>SET CONSTRAINTS</command> 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.
+   <command>SET CONSTRAINTS ALL</command> changes the mode of all deferrable
+   constraints.
+  </para>
+
+  <para>
+   When you change the mode of a constraint from <literal>DEFERRED</literal>
+   to <literal>IMMEDIATE</literal>, 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 <command>SET CONSTRAINTS</command> command.
+   If any such constraint is violated, the <command>SET CONSTRAINTS</command>
+   fails (and does not change the constraint mode).
   </para>
 
   <para>
@@ -81,6 +93,14 @@ SET CONSTRAINTS { ALL | <replaceable class="parameter">name</replaceable> [, ...
    <productname>PostgreSQL</productname>, it only applies to
    foreign-key constraints.
   </para>
+
+  <para>
+   The SQL standard says that constraint names appearing in <command>SET
+   CONSTRAINTS</command> can be schema-qualified.  This is not yet
+   supported by <productname>PostgreSQL</productname>: the names must
+   be unqualified, and all constraints matching the command will be
+   affected no matter which schema they are in.
+  </para>
  </refsect1>
 </refentry>