From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 17 Mar 2010 15:55:55 +0000 (+0000)
Subject: Fix incorrect example in CREATE INDEX reference page, per Josh Kupershmidt.
X-Git-Tag: REL8_4_4~44
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=3c1e84ad00615a39a7fbcaa9ee75e7711eb82cd4;p=postgresql

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 49352accae..5104a656e9 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.71 2009/03/24 20:17:08 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_index.sgml,v 1.71.2.1 2010/03/17 15:55:55 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -264,10 +264,10 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] <replaceable class="parameter">name</re
    <title id="SQL-CREATEINDEX-storage-parameters-title">Index Storage Parameters</title>
 
    <para>
-    The <literal>WITH</> clause can specify <firstterm>storage parameters</>
-    for indexes.  Each index method can have its own set of allowed storage
-    parameters.  The <literal>B-tree</literal>, <literal>hash</literal> and
-    <literal>GiST</literal> built-in index methods all accept a single parameter:
+    The optional <literal>WITH</> clause specifies <firstterm>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:
    </para>
 
    <variablelist>
@@ -279,10 +279,11 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] <replaceable class="parameter">name</re
       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
@@ -295,7 +296,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] <replaceable class="parameter">name</re
    </variablelist>
 
    <para>
-    <literal>GIN</literal> indexes accept a different parameter:
+    GIN indexes accept a different parameter:
    </para>
 
    <variablelist>
@@ -371,7 +372,7 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] <replaceable class="parameter">name</re
     command will fail but leave behind an <quote>invalid</> index. This index
     will be ignored for querying purposes because it might be incomplete;
     however it will still consume update overhead. The <application>psql</>
-    <command>\d</> command will mark such an index as <literal>INVALID</>:
+    <command>\d</> command will report such an index as <literal>INVALID</>:
 
 <programlisting>
 postgres=# \d tab
@@ -455,8 +456,8 @@ Indexes:
   <para>
    For index methods that support ordered scans (currently, only B-tree),
    the optional clauses <literal>ASC</>, <literal>DESC</>, <literal>NULLS
-   FIRST</>, and/or <literal>NULLS LAST</> can be specified to reverse
-   the normal sort direction of the index.  Since an ordered index can be
+   FIRST</>, and/or <literal>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 <literal>DESC</> index &mdash; that sort ordering is already
    available with a regular index.  The value of these options is that
@@ -535,7 +536,7 @@ CREATE UNIQUE INDEX title_idx ON films (title) WITH (fillfactor = 70);
   <para>
    To create a <acronym>GIN</> index with fast updates disabled:
 <programlisting>
-CREATE INDEX gin_idx ON documents_table (locations) WITH (fastupdate = off);
+CREATE INDEX gin_idx ON documents_table USING gin (locations) WITH (fastupdate = off);
 </programlisting>
   </para>
 
@@ -548,22 +549,17 @@ CREATE INDEX code_idx ON films(code) TABLESPACE indexspace;
 </programlisting>
   </para>
 
-<!--
-<comment>
-Is this example correct?
-</comment>
   <para>
    To create a GiST index on a point attribute so that we
    can efficiently use box operators on the result of the
    conversion function:
   <programlisting>
 CREATE INDEX pointloc
-    ON points USING GIST (point2box(location) box_ops);
+    ON points USING gist (box(location,location));
 SELECT * FROM points
-    WHERE point2box(points.pointloc) = boxes.box;
+    WHERE box(location,location) &amp;&amp; '(0,0),(1,1)'::box;
   </programlisting>
   </para>
--->
 
   <para>
    To create an index without locking out writes to the table: