enable_constraint_exclusion => constraint_exclusion

Also improve wording.

doc/TODO

@@ -385,7 +385,7 @@ SQL Commands
 
 * Add GUC to issue notice about queries that use unjoined tables
 * Allow EXPLAIN to identify tables that were skipped because of 
-  enable_constraint_exclusion
+  constraint_exclusion
 * Allow EXPLAIN output to be more easily processed by scripts
 
 
@@ -769,7 +769,7 @@ Indexes
 * Allow the creation of indexes with mixed ascending/descending specifiers
 * -Fix incorrect rtree results due to wrong assumptions about "over"
   operator semantics
-* Allow enable_constraint_exclusion to work for UNIONs like it does for
+* Allow constraint_exclusion to work for UNIONs like it does for
   inheritance, and allow it to work for UPDATE and DELETE queries
 
 

doc/src/FAQ/TODO.html

@@ -355,7 +355,7 @@ first.
 </p>
   </li><li>Add GUC to issue notice about queries that use unjoined tables
   </li><li>Allow EXPLAIN to identify tables that were skipped because of 
-  enable_constraint_exclusion
+  constraint_exclusion
   </li><li>Allow EXPLAIN output to be more easily processed by scripts
   </li><li>CREATE
   <ul>
@@ -694,7 +694,7 @@ first.
   </li><li>Allow the creation of indexes with mixed ascending/descending specifiers
   </li><li>-<em>Fix incorrect rtree results due to wrong assumptions about "over"</em>
   operator semantics
-  </li><li>Allow enable_constraint_exclusion to work for UNIONs like it does for
+  </li><li>Allow constraint_exclusion to work for UNIONs like it does for
   inheritance, and allow it to work for UPDATE and DELETE queries
   </li><li>GIST
   <ul>

doc/src/sgml/runtime.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.346 2005/08/21 03:39:26 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.347 2005/08/22 17:34:56 momjian Exp $
 -->
 
 <chapter Id="runtime">
@@ -2352,24 +2352,24 @@ archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-enable-constraint-exclusion" xreflabel="enable_constraint_exclusion">
-      <term><varname>enable_constraint_exclusion</varname> (<type>boolean</type>)</term>
+     <varlistentry id="guc-constraint-exclusion" xreflabel="constraint_exclusion">
+      <term><varname>constraint_exclusion</varname> (<type>boolean</type>)</term>
       <indexterm>
        <primary>constraint exclusion</primary>
       </indexterm>
       <indexterm>
-       <primary><varname>enable_constraint_exclusion</> configuration parameter</primary>
+       <primary><varname>constraint_exclusion</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
-        Enables or disables the query planner's use of table constraints.
-        The default is <literal>off</>.
+        Enables or disables the query planner's use of table constraints to
+        limit table access.  The default is <literal>off</>.
        </para>
 
        <para>
         When this parameter is <literal>on</>, the planner compares query
-        conditions to table CHECK constraints, and omits scanning tables
-        for which the conditions contradict the constraints.  (Presently
+        conditions with table CHECK constraints, and omits scanning tables
+        where the conditions contradict the constraints.  (Presently
         this is done only for child tables of inheritance scans.)  For
         example:
 
@@ -2387,15 +2387,15 @@ SELECT * FROM parent WHERE key = 2400;
        </para>
 
        <para>
-        Currently, <varname>enable_constraint_exclusion</> defaults to
-        <literal>off</>, because it creates a risk of wrong answers when
-        query plans are cached: if a table constraint is changed or dropped,
-        the previously generated plan may now be wrong, and there is no
+        Currently, <varname>constraint_exclusion</> defaults to
+        <literal>off</>, because it risks incorrect results if
+        query plans are cached --- if a table constraint is changed or dropped,
+        the previously generated plan might now be wrong, and there is no
         built-in mechanism to force re-planning.  (This deficiency will
         probably be addressed in a future
         <productname>PostgreSQL</productname> release.)  Another reason
         for keeping it off is that the constraint checks are relatively
-        expensive to make, and in many circumstances will yield no savings.
+        expensive, and in many circumstances will yield no savings.
         It is recommended to turn this on only if you are actually using
         partitioned tables designed to take advantage of the feature.
        </para>