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).

Simon Riggs

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index fbf4fda64bd0d8520e9cccf89dcd091697da3e19..8a3b2ebc7f37f20fddff0e11db756019e7c38b16 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Data Definition
@@ -2657,36 +2657,6 @@ ALTER TABLE measurement_y2006m02 INHERIT measurement;
     
    
 
-   
-   Caveats
- 
-   
-    The following caveats apply to partitioned tables:
-   
-    
-     
-      There is currently no way to verify that all of the
-      CHECK constraints are mutually
-      exclusive. Care is required by the database designer.
-     
-    
-
-    
-     
-      There is currently no simple way to specify that rows must not be
-      inserted into the master table. A CHECK (false)
-      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 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.)
-     
-    
-   
-   
-   
-
    
    Partitioning and Constraint Exclusion
 
@@ -2768,9 +2738,39 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2006-01-01';
     a large part of the partition or just a small part.  An index will
     be helpful in the latter case but not the former.
    
+   
+
+   
+   Caveats
+ 
+   
+    The following caveats apply to partitioned tables:
+   
+    
+     
+      There is currently no way to verify that all of the
+      CHECK constraints are mutually
+      exclusive. Care is required by the database designer.
+     
+    
+
+    
+     
+      There is currently no simple way to specify that rows must not be
+      inserted into the master table. A CHECK (false)
+      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 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.)
+     
+    
+   
+   
 
    
-    The following caveats apply:
+    The following caveats apply to constraint exclusion: