Fix incorrect example in CREATE INDEX reference page, per Josh Kupershmidt.

Also fix and uncomment an old example of creating a GIST index, and make
a couple of other minor editorial adjustments.

diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index 1966cb9daeb4d85f4b1196082055cb7c30302b21..ec1807a370b999d2e37dc4708ea95ae60d088ac4 100644 (file)
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -1,5 +1,5 @@
 
 
@@ -266,10 +266,10 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name
    Index Storage Parameters
 
    
-    The WITH clause can specify storage parameters
-    for indexes.  Each index method can have its own set of allowed storage
-    parameters.  The B-tree, hash and
-    GiST built-in index methods all accept a single parameter:
+    The optional WITH clause specifies storage
+    parameters for the index.  Each index method has its own set of allowed
+    storage parameters.  The B-tree, hash and GiST index methods all accept a
+    single parameter:
    
 
    
@@ -281,10 +281,11 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name
       The fillfactor for an index is a percentage that determines how full
       the index method will try to pack index pages.  For B-trees, leaf pages
       are filled to this percentage during initial index build, and also
-      when extending the index at the right (largest key values).  If pages
+      when extending the index at the right (adding new largest key values).
+      If pages
       subsequently become completely full, they will be split, leading to
       gradual degradation in the index's efficiency.  B-trees use a default
-      fillfactor of 90, but any value from 10 to 100 can be selected.
+      fillfactor of 90, but any integer value from 10 to 100 can be selected.
       If the table is static then fillfactor 100 is best to minimize the
       index's physical size, but for heavily updated tables a smaller
       fillfactor is better to minimize the need for page splits.  The
@@ -297,7 +298,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name
    
 
    
-    GIN indexes accept a different parameter:
+    GIN indexes accept a different parameter:
    
 
    
@@ -373,7 +374,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ name
     command will fail but leave behind an invalid index. This index
     will be ignored for querying purposes because it might be incomplete;
     however it will still consume update overhead. The psql
-    \d command will mark such an index as INVALID:
+    \d command will report such an index as INVALID:
 
 
 postgres=# \d tab
@@ -457,8 +458,8 @@ Indexes:
   
    For index methods that support ordered scans (currently, only B-tree),
    the optional clauses ASC, DESC, NULLS
-   FIRST, and/or NULLS LAST can be specified to reverse
-   the normal sort direction of the index.  Since an ordered index can be
+   FIRST, and/or NULLS LAST can be specified to modify
+   the sort ordering of the index.  Since an ordered index can be
    scanned either forward or backward, it is not normally useful to create a
    single-column DESC index — that sort ordering is already
    available with a regular index.  The value of these options is that
@@ -539,7 +540,7 @@ CREATE UNIQUE INDEX title_idx ON films (title) WITH (fillfactor = 70);
   
    To create a GIN index with fast updates disabled:
 
-CREATE INDEX gin_idx ON documents_table (locations) WITH (fastupdate = off);
+CREATE INDEX gin_idx ON documents_table USING gin (locations) WITH (fastupdate = off);
 
   
 
@@ -552,22 +553,17 @@ CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;
 
   
 
-
 
   
    To create an index without locking out writes to the table: