I noticed that the Partitioning section of the docs has *two* sections
of caveats in different places, but close together. One called caveats,
one not. That looks like it just led to somebody not reading some
appropriate caveats in the second group of caveats (on -admin).

Doc patch only. Combines both sets of caveats into one section, still
called same thing as previous first Caveat section.

Passes SGML make

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com

Index: doc/src/sgml/ddl.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ddl.sgml,v
retrieving revision 1.67
diff -c -r1.67 ddl.sgml
*** doc/src/sgml/ddl.sgml	23 Oct 2006 18:10:30 -0000	1.67
--- doc/src/sgml/ddl.sgml	16 Nov 2006 17:43:51 -0000
***************
*** 2657,2692 ****
      </para>
     </sect2>
  
-    <sect2 id="ddl-partitioning-caveats">
-    <title>Caveats</title>
-  
-    <para>
-     The following caveats apply to partitioned tables:
-    <itemizedlist>
-     <listitem>
-      <para>
-       There is currently no way to verify that all of the
-       <literal>CHECK</literal> constraints are mutually
-       exclusive. Care is required by the database designer.
-      </para>
-     </listitem>
- 
-     <listitem>
-      <para>
-       There is currently no simple way to specify that rows must not be
-       inserted into the master table. A <literal>CHECK (false)</literal>
-       constraint on the master table would be inherited by all child
-       tables, so that cannot be used for this purpose.  One possibility is
-       to set up an <literal>ON INSERT</> trigger on the master table that
-       always raises an error.  (Alternatively, such a trigger could be
-       used to redirect the data into the proper child table, instead of
-       using a set of rules as suggested above.)
-      </para>
-     </listitem>
-    </itemizedlist>
-    </para>
-    </sect2>
- 
     <sect2 id="ddl-partitioning-constraint-exclusion">
     <title>Partitioning and Constraint Exclusion</title>
  
--- 2657,2662 ----
***************
*** 2768,2776 ****
      a large part of the partition or just a small part.  An index will
      be helpful in the latter case but not the former.
     </para>
  
     <para>
!     The following caveats apply:
  
     <itemizedlist>
      <listitem>
--- 2738,2776 ----
      a large part of the partition or just a small part.  An index will
      be helpful in the latter case but not the former.
     </para>
+    </sect2>
+ 
+    <sect2 id="ddl-partitioning-caveats">
+    <title>Caveats</title>
+  
+    <para>
+     The following caveats apply to partitioned tables:
+    <itemizedlist>
+     <listitem>
+      <para>
+       There is currently no way to verify that all of the
+       <literal>CHECK</literal> constraints are mutually
+       exclusive. Care is required by the database designer.
+      </para>
+     </listitem>
+ 
+     <listitem>
+      <para>
+       There is currently no simple way to specify that rows must not be
+       inserted into the master table. A <literal>CHECK (false)</literal>
+       constraint on the master table would be inherited by all child
+       tables, so that cannot be used for this purpose.  One possibility is
+       to set up an <literal>ON INSERT</> trigger on the master table that
+       always raises an error.  (Alternatively, such a trigger could be
+       used to redirect the data into the proper child table, instead of
+       using a set of rules as suggested above.)
+      </para>
+     </listitem>
+    </itemizedlist>
+    </para>
  
     <para>
!     The following caveats apply to constraint exclusion:
  
     <itemizedlist>
      <listitem>
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to