Some minor improvements to the CE docs. Also fix a bit of SGML markup

elsewhere.

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 0b2ca56a121d4abab5b85024314899238ec4e4f8..757e5d6183c94218fe01ea595f00e53c821080f0 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Data Definition
@@ -1406,32 +1406,42 @@ SELECT * from cities*;
     
    
 
-    The benefits will normally be worthwhile only when a data table would
-    otherwise be very large. That is for you to judge, though would not
-    usually be lower than the size of physical RAM on the database server.
+    The benefits will normally be worthwhile only when a table would
+    otherwise be very large. The exact point at which a table will
+    benefit from partitioning depends on the application, although the
+    size of the table should usually exceed the physical memory of the
+    database server.
    
 
    
-    In PostgreSQL &version;, the following
-    partitioning types are supported:
+    The following partitioning types are supported by
+    PostgreSQL &version;:
 
-    
-     
-      
-       "Range Partitioning" where the table is partitioned along a
-       "range" defined by a single column or set of columns, with no
-       overlap between partitions. Examples might be a date range or a
-       range of identifiers for particular business objects.
-      
-     
+    
+     
+      Range Partitioning
 
-     
-      
-       "List Partitioning" where the table is partitioned by
-       explicitly listing which values relate to each partition.
-      
-     
-    
+      
+       
+        The table is partitioned along a range defined
+        by a single column or set of columns, with no overlap between
+        partitions. Examples might be a date range or a range of
+        identifiers for particular business objects.
+       
+      
+     
+
+     
+      List Partitioning
+
+      
+       
+        The table is partitioned by explicitly listing which values
+        relate to each partition.
+       
+      
+     
+    
 
     Hash partitioning is not currently supported.
    
@@ -1471,8 +1481,7 @@ SELECT * from cities*;
 
        
         We will refer to the child tables as partitions, though they
-        are in every way just normal PostgreSQL
-        tables.
+        are in every way normal PostgreSQL tables.
        
       
 
@@ -1485,15 +1494,16 @@ SELECT * from cities*;
         for constraint exclusion. Simple examples would be:
 
 CHECK ( x = 1 )
-CHECK ( county IN ('Oxfordshire','Buckinghamshire','Warwickshire'))
+CHECK ( county IN ( 'Oxfordshire','Buckinghamshire','Warwickshire' ))
 CHECK ( outletID BETWEEN 1 AND 99 )
 
 
-        These can be linked together with boolean operators AND and OR to
-        form complex constraints. Note that there is no difference in syntax
-        between Range and List Partitioning mechanisms; those terms are
-        descriptive only. Ensure that the set of values in each child table
-        do not overlap.
+        These can be linked together with the boolean operators
+        AND and OR to form
+        complex constraints. Note that there is no difference in
+        syntax between range and list partitioning; those terms are
+        descriptive only. Ensure that the set of values in each child
+        table do not overlap.
        
       
 
@@ -1712,19 +1722,22 @@ DO INSTEAD
 
     
      
-      For some datatypes you must explicitly coerce the constant values
-      into the datatype of the column. The following constraint will
-      work if x is an INTEGER datatype, but not if x is BIGINT datatype.
+      For some datatypes you must explicitly coerce the constant
+      values into the datatype of the column. The following constraint
+      will work if x is an integer
+      datatype, but not if x is a
+      bigint:
 
 CHECK ( x = 1 )
 
-      For BIGINT we must use a constraint like:
+      For bigint we must use a constraint like:
 
 CHECK ( x = 1::bigint )
 
-      The issue is not restricted to BIGINT datatypes but can occur whenever
-      the default datatype of the constant does not match the datatype of
-      the column to which it is being compared.
+      The problem is not limited to the bigint datatype
+      — it can occur whenever the default datatype of the
+      constant does not match the datatype of the column to which it
+      is being compared.
      
     
 
@@ -2312,8 +2325,8 @@ REVOKE ALL ON accounts FROM PUBLIC;
    
 
    
-    To create a schema, use the command <literal>CREATE
-    SCHEMAliteral>.  Give the schema a name of your choice.  For
+    To create a schema, use the command <command>CREATE
+    SCHEMAcommand>.  Give the schema a name of your choice.  For
     example:
 
 CREATE SCHEMA myschema;

diff --git a/doc/src/sgml/ref/create_role.sgml b/doc/src/sgml/ref/create_role.sgml
index 599ac1898aa817a5c97990a78022654e4b4cf7d2..16cd16ef5acccaf7d82480b86e0829ffaf8f02b6 100644 (file)
--- a/doc/src/sgml/ref/create_role.sgml
+++ b/doc/src/sgml/ref/create_role.sgml
@@ -1,5 +1,5 @@
 
 
@@ -112,7 +112,7 @@ where option can be:
       
        
         These clauses determine whether a role will be permitted to
-        create new roles (that is, execute <literal>CREATE ROLE>).
+        create new roles (that is, execute <command>CREATE ROLE>).
         A role with CREATEROLE privilege can also alter
         and drop other roles.
         If not specified,
@@ -374,7 +374,7 @@ CREATE ROLE jonathan LOGIN;
 
 CREATE USER davide WITH PASSWORD 'jw8s0F4';
 
-   (<literal>CREATE USER is the same as >CREATE ROLE except
+   (<command>CREATE USER is the same as >CREATE ROLE except
    that it implies LOGIN.)