Change "indices" to "indexes", per OED.

a6677f0f · Peter Eisentraut · f000ffd2 · a6677f0f · a6677f0f · a6677f0f
Commit a6677f0f authored May 17, 2001 by Peter Eisentraut
20 changed files
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.13 2000/12/26 00:10:37 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/arch-dev.sgml,v 2.14 2001/05/17 21:50:15 petere Exp $
 -->
 <chapter id="overview">
@@ -603,7 +603,7 @@ current context are performed.
    <para>
     The planner/optimizer decides which plans should be generated
-     based upon the types of indices defined on the relations appearing in
+     based upon the types of indexes defined on the relations appearing in
     a query. There is always the possibility of performing a
     sequential scan on a relation, so a plan using only
     sequential scans is always created. Assume an index is defined on a
@@ -612,7 +612,7 @@ current context are performed.
     <literal>relation.attribute OPR constant</literal>. If
     <literal>relation.attribute</literal> happens to match the key of the B-tree
     index and <literal>OPR</literal> is anything but '&lt;&gt;' another plan is created using
-     the B-tree index to scan the relation. If there are further indices
+     the B-tree index to scan the relation. If there are further indexes
     present and the restrictions in the query happen to match a key of an
     index further plans will be considered.
    </para>
@@ -889,7 +889,7 @@ The {\tt AGG} node is followed by a {\tt GRP} node. The implementation
 of the {\it grouping} logic needs a sorted table for its operation so
 the {\tt GRP} node is followed by a {\tt SORT} node. The {\tt SORT}
 operation gets its tuples from a kind of {\tt Scan} node (if no
-indices are present this will be a simple {\tt SeqScan} node). Any
+indexes are present this will be a simple {\tt SeqScan} node). Any
 qualifications present are attached to the {\tt Scan} node. Figure
 \ref{plan_having} shows the {\it plan} created for the query given in
 example \ref{having}.

--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.8 2001/05/17 21:12:48 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v 2.9 2001/05/17 21:50:15 petere Exp $ -->
 <chapter id="backup">
 <title>Backup and Restore</title>
@@ -355,7 +355,7 @@ tar -cf backup.tar /usr/local/pgsql/data
   Also note that the file system backup will not necessarily be
   smaller than an SQL dump. On the contrary, it will most likely be
   larger. (<application>pg_dump</application> does not need to dump
-   the contents of indices for example, just the commands to recreate
+   the contents of indexes for example, just the commands to recreate
   them.)
  </para>

--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.10 2001/05/17 21:50:15 petere Exp $
 -->
 <chapter id="extend">
@@ -96,7 +96,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
    file that stores all rows of a table)  but  the
    user can "look inside" at the attributes of these types
    from the query language and optimize their retrieval by
-    (for example) defining indices on the attributes.
+    (for example) defining indexes on the attributes.
    <productname>Postgres</productname>  base  types are further
    divided into built-in
    types and user-defined  types.   Built-in  types  (like
@@ -149,7 +149,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
       </row>
       <row>
 	<entry>pg_index</entry>
-	<entry> secondary indices</entry>
+	<entry> secondary indexes</entry>
       </row>
       <row>
 	<entry>pg_proc</entry>
@@ -256,7 +256,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/extend.sgml,v 1.9 2001/01/13 23:58:55 peter
       pg_am,   pg_amop,   pg_amproc,  pg_operator  and
       pg_opclass are particularly hard  to  understand
       and  will  be described in depth (in the section
-       on interfacing types and operators  to  indices)
+       on interfacing types and operators  to  indexes)
       after we have discussed basic extensions.
      </para>
     </listitem>

--- a/doc/src/sgml/geqo.sgml
+++ b/doc/src/sgml/geqo.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.16 2001/04/20 15:52:33 thomas Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/geqo.sgml,v 1.17 2001/05/17 21:50:15 petere Exp $
 Genetic Optimizer
 -->
@@ -51,8 +51,8 @@ Genetic Optimizer
    <firstterm>join methods</firstterm>
    (e.g., nested loop, hash join, merge join in <productname>Postgres</productname>) to
    process individual <command>join</command>s and a diversity of
-    <firstterm>indices</firstterm> (e.g., r-tree,
+    <firstterm>indexes</firstterm> (e.g., R-tree,
-    b-tree, hash in <productname>Postgres</productname>) as access paths for relations.
+    B-tree, hash in <productname>Postgres</productname>) as access paths for relations.
   </para>
   <para>

--- a/doc/src/sgml/gist.sgml
+++ b/doc/src/sgml/gist.sgml
@@ -8,7 +8,7 @@
 </AuthorGroup>
 <Date>Transcribed 1998-02-19</Date>
 </DocInfo>
-<Title>GiST Indices</Title>
+<Title>GiST Indexes</Title>
 <Para>
 The information about GIST is at

--- a/doc/src/sgml/indices.sgml
+++ b/doc/src/sgml/indices.sgml
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.16 2001/05/12 22:51:34 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.17 2001/05/17 21:50:16 petere Exp $ -->
-<chapter id="indices">
+<chapter id="indexes">
- <title id="indices-title">Indices</title>
+ <title id="indexes-title">Indices</title>
- <indexterm zone="indices">
+ <indexterm zone="indexes">
-  <primary>indices</primary>
- </indexterm>
- <indexterm>
  <primary>indexes</primary>
-  <see>indices</see>
 </indexterm>
 <para>
-  Indices are a common way to enhance database performance.  An index
+  Indexes are a common way to enhance database performance.  An index
  allows the database server to find and retrieve specific rows much
-  faster than it could do without an index.  But indices also add
+  faster than it could do without an index.  But indexes also add
  overhead to the database system as a whole, so they should be used
  sensibly.
 </para>
- <sect1 id="indices-intro">
+ <sect1 id="indexes-intro">
  <title>Introduction</title>
  <para>
@@ -73,7 +68,7 @@ CREATE INDEX test1_id_index ON test1 (id);
  <para>
   To remove an index, use the <command>DROP INDEX</command> command.
-   Indices can be added and removed from tables at any time.
+   Indexes can be added and removed from tables at any time.
  </para>
  <para>
@@ -88,10 +83,10 @@ CREATE INDEX test1_id_index ON test1 (id);
  </para>
  <para>
-   Indices can also benefit <command>UPDATE</command>s and
+   Indexes can also benefit <command>UPDATE</command>s and
   <command>DELETE</command>s with search conditions.  Note that a
   query or data manipulation commands can only use at most one index
-   per table.  Indices can also be used in table join methods.  Thus,
+   per table.  Indexes can also be used in table join methods.  Thus,
   an index defined on a column that is part of a join condition can
   significantly speed up queries with joins.
  </para>
@@ -99,13 +94,13 @@ CREATE INDEX test1_id_index ON test1 (id);
  <para>
   When an index is created, it has to be kept synchronized with the
   table.  This adds overhead to data manipulation operations.
-   Therefore indices that are non-essential or do not get used at all
+   Therefore indexes that are non-essential or do not get used at all
   should be removed.
  </para>
 </sect1>
- <sect1 id="indices-types">
+ <sect1 id="indexes-types">
  <title>Index Types</title>
  <para>
@@ -113,12 +108,12 @@ CREATE INDEX test1_id_index ON test1 (id);
   B-tree, R-tree, and Hash.  Each index type is more appropriate for
   a particular query type because of the algorithm it uses.
   <indexterm>
-    <primary>indices</primary>
+    <primary>indexes</primary>
    <secondary>B-tree</secondary>
   </indexterm>
   <indexterm>
    <primary>B-tree</primary>
-    <see>indices</see>
+    <see>indexes</see>
   </indexterm>
   By
   default, the <command>CREATE INDEX</command> command will create a
@@ -138,14 +133,14 @@ CREATE INDEX test1_id_index ON test1 (id);
  <para>
   <indexterm>
-    <primary>indices</primary>
+    <primary>indexes</primary>
    <secondary>R-tree</secondary>
   </indexterm>
   <indexterm>
    <primary>R-tree</primary>
-    <see>indices</see>
+    <see>indexes</see>
   </indexterm>
-   R-tree indices are especially suited for spacial data.  To create
+   R-tree indexes are especially suited for spacial data.  To create
   an R-tree index, use a command of the form
 <synopsis>
 CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> USING RTREE (<replaceable>column</replaceable>);
@@ -169,12 +164,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
  <para>
   <indexterm>
-    <primary>indices</primary>
+    <primary>indexes</primary>
    <secondary>hash</secondary>
   </indexterm>
   <indexterm>
    <primary>hash</primary>
-    <see>indices</see>
+    <see>indexes</see>
   </indexterm>
   The query optimizer will consider using a hash index whenever an
   indexed column is involved in a comparison using the
@@ -185,12 +180,12 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
 </synopsis>
   <note>
    <para>
-     Because of the limited utility of hash indices, a B-tree index
+     Because of the limited utility of hash indexes, a B-tree index
     should generally be preferred over a hash index.  We do not have
-     sufficient evidence that hash indices are actually faster than
+     sufficient evidence that hash indexes are actually faster than
     B-trees even for <literal>=</literal> comparisons.  Moreover,
-     hash indices require coarser locks; see <xref
+     hash indexes require coarser locks; see <xref
-     linkend="locking-indices">.
+     linkend="locking-indexes">.
    </para>
   </note>  
  </para>
@@ -208,11 +203,11 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
 </sect1>
- <sect1 id="indices-multicolumn">
+ <sect1 id="indexes-multicolumn">
-  <title>Multi-Column Indices</title>
+  <title>Multi-Column Indexes</title>
-  <indexterm zone="indices-multicolumn">
+  <indexterm zone="indexes-multicolumn">
-   <primary>indices</primary>
+   <primary>indexes</primary>
   <secondary>multi-column</secondary>
  </indexterm>
@@ -241,7 +236,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
  <para>
   Currently, only the B-tree implementation supports multi-column
-   indices.  Up to 16 columns may be specified.  (This limit can be
+   indexes.  Up to 16 columns may be specified.  (This limit can be
   altered when building <productname>Postgres</productname>; see the
   file <filename>config.h</filename>.)
  </para>
@@ -274,7 +269,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
  </para>
  <para>
-   Multi-column indices should be used sparingly.  Most of the time,
+   Multi-column indexes should be used sparingly.  Most of the time,
   an index on a single column is sufficient and saves space and time.
   Indexes with more than three columns are almost certainly
   inappropriate.
@@ -282,11 +277,11 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
 </sect1>
- <sect1 id="indices-unique">
+ <sect1 id="indexes-unique">
-  <title>Unique Indices</title>
+  <title>Unique Indexes</title>
-  <indexterm zone="indices-unique">
+  <indexterm zone="indexes-unique">
-   <primary>indices</primary>
+   <primary>indexes</primary>
   <secondary>unique</secondary>
  </indexterm>
@@ -296,7 +291,7 @@ SELECT name FROM test2 WHERE major = <replaceable>constant</replaceable> OR mino
 <synopsis>
 CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable> (<replaceable>column</replaceable> <optional>, ...</optional>);
 </synopsis>
-   Only B-tree indices can be declared unique.
+   Only B-tree indexes can be declared unique.
  </para>
  <para>
@@ -307,7 +302,7 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
  <para>
   <productname>PostgreSQL</productname> automatically creates unique
-   indices when a table is declared with a unique constraint or a
+   indexes when a table is declared with a unique constraint or a
   primary key, on the columns that make up the primary key or unique
   columns (a multi-column index, if appropriate), to enforce that
   constraint.  A unique index can be added to a table at any later
@@ -317,18 +312,18 @@ CREATE UNIQUE INDEX <replaceable>name</replaceable> ON <replaceable>table</repla
 </sect1>
- <sect1 id="indices-functional">
+ <sect1 id="indexes-functional">
-  <title>Functional Indices</title>
+  <title>Functional Indexes</title>
-  <indexterm zone="indices-functional">
+  <indexterm zone="indexes-functional">
-   <primary>indices</primary>
+   <primary>indexes</primary>
   <secondary>on functions</secondary>
  </indexterm>
  <para>
   For a <firstterm>functional index</firstterm>, an index is defined
   on the result of a function applied to one or more columns of a
-   single table.  Functional indices can be used to obtain fast access
+   single table.  Functional indexes can be used to obtain fast access
   to data based on the result of function calls.
  </para>
@@ -349,9 +344,9 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
  <para>
   The function in the index definition can take more than one
   argument, but they must be table columns, not constants.
-   Functional indices are always single-column (namely, the function
+   Functional indexes are always single-column (namely, the function
   result) even if the function uses more than one input field; there
-   cannot be multi-column indices that contain function calls.
+   cannot be multi-column indexes that contain function calls.
  </para>
  <tip>
@@ -364,7 +359,7 @@ CREATE INDEX test1_lower_col1_idx ON test1 (lower(col1));
 </sect1>
- <sect1 id="indices-opclass">
+ <sect1 id="indexes-opclass">
  <title>Operator Classes</title>
  <para>
@@ -390,7 +385,7 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
    <listitem>
     <para>
      The operator classes <literal>box_ops</literal> and
-      <literal>bigbox_ops</literal> both support R-tree indices on the
+      <literal>bigbox_ops</literal> both support R-tree indexes on the
      <literal>box</literal> data type.  The difference between them is
      that <literal>bigbox_ops</literal> scales box coordinates down,
      to avoid floating point exceptions from doing multiplication,
@@ -540,11 +535,11 @@ Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
   <para>
    As for why no non-unique keys are defined explicitly in standard
    <acronym>SQL</acronym> syntax? Well, you
-    must understand that indices are implementation-dependent.
+    must understand that indexes are implementation-dependent.
    <acronym>SQL</acronym> does not
    define the implementation, merely the relations between data in the
    database. <productname>Postgres</productname> does allow
-    non-unique indices, but indices
+    non-unique indexes, but indexes
    used to enforce <acronym>SQL</acronym> keys are always unique.
   </para>
@@ -579,7 +574,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
    <acronym>RDBMS</acronym> provider gives you
    - be it an index, my imaginary MEMSTORE command, or an intelligent
    <acronym>RDBMS</acronym>
-    that creates indices without your knowledge based on the fact that you have
+    that creates indexes without your knowledge based on the fact that you have
    sent it many queries based on a specific combination of keys... (It learns
    from experience).
   </para>
@@ -587,10 +582,10 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
  <sect1 id="partial-index">
-   <title id="partial-index-title">Partial Indices</title>
+   <title id="partial-index-title">Partial Indexes</title>
  <indexterm zone="partial-index">
-   <primary>indices</primary>
+   <primary>indexes</primary>
   <secondary>partial</secondary>
  </indexterm>
@@ -611,7 +606,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
   <note>
    <title>Note</title>
    <para>
-     Partial indices are not currently supported by
+     Partial indexes are not currently supported by
     <productname>PostgreSQL</productname>, but they were once supported
     by its predecessor <productname>Postgres</productname>, and much
     of the code is still there.  We hope to revive support for this
@@ -623,14 +618,14 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
    A <firstterm>partial index</firstterm>
    is an index built over a subset of a table; the subset is defined by
    a predicate.  <productname>Postgres</productname>
-    supported partial indices with arbitrary
+    supported partial indexes with arbitrary
    predicates.  I believe IBM's <productname>DB2</productname>
-    for AS/400 supports partial indices
+    for AS/400 supports partial indexes
    using single-clause predicates.
   </para>
   <para>
-    The main motivation for partial indices is this:
+    The main motivation for partial indexes is this:
    if all of the queries you ask that can
    profitably use an index fall into a certain range, why build an index
    over the whole table and suffer the associated space/time costs?
@@ -640,9 +635,9 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
   </para>
   <para>
-    The machinery to build, update and query partial indices isn't too
+    The machinery to build, update and query partial indexes isn't too
-    bad.  The hairy parts are index selection (which indices do I build?)
+    bad.  The hairy parts are index selection (which indexes do I build?)
-    and query optimization (which indices do I use?); i.e., the parts
+    and query optimization (which indexes do I use?); i.e., the parts
    that involve deciding what predicate(s) match the workload/query in
    some useful way.  For those who are into database theory, the problems
    are basically analogous to the corresponding materialized view

--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.14 2001/05/12 22:51:35 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.15 2001/05/17 21:50:16 petere Exp $
 -->
 <chapter id="mvcc">
@@ -554,8 +554,8 @@ ERROR:  Can't serialize access due to concurrent update
   </sect2>
  </sect1>
-  <sect1 id="locking-indices">
+  <sect1 id="locking-indexes">
-   <title>Locking and Indices</title>
+   <title>Locking and Indexes</title>
   <para>
    Though <productname>Postgres</productname>
@@ -571,7 +571,7 @@ ERROR:  Can't serialize access due to concurrent update
    <variablelist>
     <varlistentry>
      <term>
-       GiST and R-Tree indices
+       GiST and R-Tree indexes
      </term>
      <listitem>
       <para>
@@ -583,7 +583,7 @@ ERROR:  Can't serialize access due to concurrent update
     <varlistentry>
      <term>
-       Hash indices
+       Hash indexes
      </term>
      <listitem>
       <para>
@@ -600,7 +600,7 @@ ERROR:  Can't serialize access due to concurrent update
     <varlistentry>
      <term>
-       Btree indices
+       B-tree indexes
      </term>
      <listitem>
       <para>
@@ -610,7 +610,7 @@ ERROR:  Can't serialize access due to concurrent update
       </para>
       <para>
-	Btree indices provide the highest concurrency without deadlock
+	B-tree indexes provide the highest concurrency without deadlock
 	conditions.
       </para>
      </listitem>
@@ -619,7 +619,7 @@ ERROR:  Can't serialize access due to concurrent update
   </para>
   <para>
-    In short, btree indices are the recommended index type for concurrent
+    In short, B-tree indexes are the recommended index type for concurrent
    applications.
   </para>
  </sect1>

--- a/doc/src/sgml/page.sgml
+++ b/doc/src/sgml/page.sgml
@@ -23,7 +23,7 @@ refers to data that is stored in <productname>Postgres</productname> tables.
 <para>
 The following table shows how pages in both normal <productname>Postgres</productname> tables
- and <productname>Postgres</productname> indices
+ and <productname>Postgres</productname> indexes
 (e.g., a B-tree index) are structured.
 <table tocentry="1">

--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.4 2001/05/09 00:35:09 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.5 2001/05/17 21:50:16 petere Exp $
 -->
 <chapter id="performance-tips">
@@ -395,8 +395,8 @@ SELECT * FROM d LEFT JOIN
   </para>
  </sect2>
-  <sect2 id="populate-rm-indices">
+  <sect2 id="populate-rm-indexes">
-   <title>Remove Indices</title>
+   <title>Remove Indexes</title>
   <para>
    If you are loading a freshly created table, the fastest way is to

--- a/doc/src/sgml/plsql.sgml
+++ b/doc/src/sgml/plsql.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.31 2001/05/12 22:51:35 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/plsql.sgml,v 2.32 2001/05/17 21:50:16 petere Exp $
 -->
 <chapter id="plpgsql"> 
@@ -115,7 +115,7 @@ END;
    for user defined types, anything that can be defined in C language
    functions can also be done with PL/pgSQL. It is possible to
    create complex conditional computation functions and later use
-    them to define operators or use them in functional indices.
+    them to define operators or use them in functional indexes.
   </para>
  <sect2 id="plpgsql-advantages">
   <title>Advantages of Using PL/pgSQL</title>

--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.18 2001/01/13 23:58:55 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_index.sgml,v 1.19 2001/05/17 21:50:18 petere Exp $
 Postgres documentation
 -->
@@ -209,7 +209,7 @@ ERROR: Cannot create index: 'index_name' already exists.
   on the result of a user-specified function
   <replaceable class="parameter">func_name</replaceable> applied
   to one or more columns of a single table.
-   These <firstterm>functional indices</firstterm>
+   These <firstterm>functional indexes</firstterm>
   can be used to obtain fast access to data
   based on operators that would normally require some
   transformation to apply them to the base data.
@@ -217,7 +217,7 @@ ERROR: Cannot create index: 'index_name' already exists.
  <para>
   Postgres provides btree, rtree and hash access methods for
-   indices.  The btree access method is an implementation of
+   indexes.  The btree access method is an implementation of
   Lehman-Yao high-concurrency btrees.  The rtree access method
   implements standard rtrees using Guttman's quadratic split algorithm.
   The hash access method is an implementation of Litwin's linear
@@ -302,7 +302,7 @@ ERROR: Cannot create index: 'index_name' already exists.
    <listitem>
     <para>
      The operator classes <literal>box_ops</literal> and
-      <literal>bigbox_ops</literal> both support rtree indices on the
+      <literal>bigbox_ops</literal> both support rtree indexes on the
      <literal>box</literal> data type.
      The difference between them is that <literal>bigbox_ops</literal>
      scales box coordinates down, to avoid floating-point exceptions from

--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.32 2001/05/17 21:12:48 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v 1.33 2001/05/17 21:50:18 petere Exp $
 Postgres documentation
 -->
@@ -74,7 +74,7 @@ Postgres documentation
  <para>
   <command>pg_dump</command> 
   will produce the queries necessary to re-generate all
-   user-defined types, functions, tables, indices, aggregates, and
+   user-defined types, functions, tables, indexes, aggregates, and
   operators.  In addition, all the data is copied out in text format so
   that it can be readily copied in again, as well as imported into tools
   for editing.

--- a/doc/src/sgml/ref/pg_restore.sgml
+++ b/doc/src/sgml/ref/pg_restore.sgml
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.11 2001/05/17 21:12:48 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v 1.12 2001/05/17 21:50:18 petere Exp $ -->
 <refentry id="APP-PGRESTORE">
 <docinfo>
@@ -71,7 +71,7 @@
   or even to reorder the items prior to being restored. The archive files are designed
   to be portable across architectures. <command>pg_dump</command> will
   produce the queries necessary to re-generate all user-defined types, functions,
-   tables, indices, aggregates, and operators.  In addition, all the data is copied
+   tables, indexes, aggregates, and operators.  In addition, all the data is copied
   out (in text format for scripts) so that it can be readily copied in again.
  </para>
@@ -335,7 +335,7 @@
       <para>
        Restore items in modified OID order. By default <command>pg_dump</command> will dump items in an order convenient
        to <command>pg_dump</command>, then save the archive in a modified OID order. Most objects
-        will be restored in OID order, but some things (e.g., rules and indices) will be restored at the end of
+        will be restored in OID order, but some things (e.g., rules and indexes) will be restored at the end of
        the process irrespective of their OIDs. This option is the default.
       </para>
      </listitem>

--- a/doc/src/sgml/ref/pgaccess-ref.sgml
+++ b/doc/src/sgml/ref/pgaccess-ref.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgaccess-ref.sgml,v 1.9 2001/03/17 16:27:31 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/Attic/pgaccess-ref.sgml,v 1.10 2001/05/17 21:50:18 petere Exp $
 Postgres documentation
 -->
@@ -163,7 +163,7 @@ Postgres documentation
    <listitem>
     <para>
-      Retrieve information on tables, including owner, field information, indices.
+      Retrieve information on tables, including owner, field information, indexes.
     </para>
    </listitem>
   </itemizedlist>

--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.52 2001/05/12 19:44:45 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v 1.53 2001/05/17 21:50:18 petere Exp $
 Postgres documentation
 -->
@@ -348,7 +348,7 @@ testdb=>
 	(which could be a table, view, index, or sequence),
 	their types, and any special attributes such as <literal>NOT NULL</literal>
 	or defaults, if any.
-	If the relation is, in fact, a table, any defined indices are also listed.
+	If the relation is, in fact, a table, any defined indexes are also listed.
 	If the relation is a view, the view definition is also shown.
 	</para>
@@ -387,7 +387,7 @@ testdb=>
        Shows the descriptions of <replaceable class="parameter">object</replaceable>
        (which can be a regular expression), or of all objects if no argument is given.
        (<quote>Object</quote> covers aggregates, functions, operators, types, relations
-        (tables, views, indices, sequences, large objects), rules, and triggers.) For example:
+        (tables, views, indexes, sequences, large objects), rules, and triggers.) For example:
 <programlisting>
 => <userinput>\dd version</userinput>
              Object descriptions

--- a/doc/src/sgml/release.sgml
+++ b/doc/src/sgml/release.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.92 2001/05/17 13:28:30 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.93 2001/05/17 21:50:16 petere Exp $
 -->
 <appendix id="release">
@@ -1196,7 +1196,7 @@ subselect+CASE fixes(Tom)
 Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
 Fixes for CASE in WHERE join clauses(Tom)
 Fix BTScan abort(Tom)
-Repair the check for redundant UNIQUE and PRIMARY KEY indices(Thomas)
+Repair the check for redundant UNIQUE and PRIMARY KEY indexes(Thomas)
 Improve it so that it checks for multi-column constraints(Thomas)
 Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
 Allow BSD yacc and bison to compile pl code(Bruce)
@@ -1595,7 +1595,7 @@ Enhancements
 ------------
 Add "vacuumdb" utility
 Speed up libpq by allocating memory better(Tom)
-EXPLAIN all indices used(Tom)
+EXPLAIN all indexes used(Tom)
 Implement CASE, COALESCE, NULLIF  expression(Thomas)
 New pg_dump table output format(Constantin)
 Add string min()/max() functions(Thomas)
@@ -2029,14 +2029,14 @@ Allow index use with OR clauses(Bruce)
 Allows "SELECT NULL ORDER BY 1;"
 Explain VERBOSE prints the plan, and now pretty-prints the plan to
 the postmaster log file(Bruce)
-Add Indices display to \d command(Bruce)
+Add indexes display to \d command(Bruce)
 Allow GROUP BY on functions(David)
 New pg_class.relkind for large objects(Bruce)
 New way to send libpq NOTICE messages to a different location(Tom)
 New \w write command to psql(Bruce)
 New /contrib/findoidjoins scans oid columns to find join relationships(Bruce)
-Allow binary-compatible indices to be considered when checking for valid
+Allow binary-compatible indexes to be considered when checking for valid
-indices for restriction clauses containing a constant(Thomas)
+Indexes for restriction clauses containing a constant(Thomas)
 New ISBN/ISSN code in /contrib/isbn_issn
 Allow NOT LIKE, IN, NOT IN, BETWEEN, and NOT BETWEEN constraint(Thomas)
 New rewrite system fixes many problems with rules and views(Jan)
@@ -2502,7 +2502,7 @@ Real deadlock detection, no more timeouts(Bruce)
 Add SQL92 "constants" CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP, 
 	CURRENT_USER(Thomas)
 Modify constraint syntax to be SQL92-compliant(Thomas)
-Implement SQL92 PRIMARY KEY and UNIQUE clauses using indices(Thomas)
+Implement SQL92 PRIMARY KEY and UNIQUE clauses using indexes(Thomas)
 Recognize SQL92 syntax for FOREIGN KEY. Throw elog notice(Thomas)
 Allow NOT NULL UNIQUE constraint clause (each allowed separately before)(Thomas)
 Allow Postgres-style casting ("::") of non-constants(Thomas)
@@ -2514,14 +2514,14 @@ Implement SQL92 binary and hexadecimal string decoding (b'10' and x'1F')(Thomas)
 Support SQL92 syntax for type coercion of literal strings
 	(e.g. "DATETIME 'now'")(Thomas)
 Add conversions for int2, int4, and OID types to and from text(Thomas)
-Use shared lock when building indices(Vadim)
+Use shared lock when building indexes(Vadim)
 Free memory allocated for an user query inside transaction block after
 	this query is done, was turned off in <= 6.2.1(Vadim)
 New SQL statement CREATE PROCEDURAL LANGUAGE(Jan)
 New <productname>Postgres</productname> Procedural Language (PL) backend interface(Jan)
 Rename pg_dump -H option to -h(Bruce)
 Add Java support for passwords, European dates(Peter)
-Use indices for LIKE and ~, !~ operations(Bruce)
+Use indexes for LIKE and ~, !~ operations(Bruce)
 Add hash functions for datetime and timespan(Thomas)
 Time Travel removed(Vadim, Bruce)
 Add paging for \d and \z, and fix \i(Bruce)
@@ -2539,7 +2539,7 @@ Regression tests time zone automatically set with "setenv PGTZ PST8PDT"(Thomas)
 Add pg_description table for info on tables, columns, operators, types, and
 	aggregates(Bruce)
 Increase 16 char limit on system table/index names to 32 characters(Bruce)
-Rename system indices(Bruce)
+Rename system indexes(Bruce)
 Add 'GERMAN' option to SET DATESTYLE(Thomas)
 Define an "ISO-style" timespan output format with "hh:mm:ss" fields(Thomas)
 Allow fractional values for delta times (e.g. '2.5 days')(Thomas)
@@ -3041,7 +3041,7 @@ fix join clauses for multiple tables(Vadim)
 fix hash, hashjoin for arrays(Vadim)
 fix btree for abstime type(Vadim)
 large object fixes(Raymond)
-fix buffer leak in hash indices (Vadim)
+fix buffer leak in hash indexes (Vadim)
 fix rtree for use in inner scan (Vadim)
 fix gist for use in inner scan, cleanups (Vadim, Andrea)
 avoid unnecessary local buffers allocation (Vadim, Massimo)
@@ -3816,8 +3816,8 @@ Bug fixes:
 * allow the use of \; inside the monitor
 * the LISTEN/NOTIFY asynchronous notification mechanism now work
 * NOTIFY in rule action bodies now work
- * hash indices work, and access methods in general should perform better.
+ * hash indexes work, and access methods in general should perform better.
-   creation of large btree indices should be much faster.  (thanks to Paul
+   creation of large btree indexes should be much faster.  (thanks to Paul
   Aoki)
 Other changes and enhancements:

--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1869,7 +1869,7 @@ Merge Join
                           AND software.hostname = computer.hostname;
 </ProgramListing>
-    Since there are appropriate indices setup, the planner
+    Since there are appropriate indexes setup, the planner
    will create a plan of
 <ProgramListing>
@@ -1919,7 +1919,7 @@ Merge Join
    get invoked once for any of the 2000 old computers that
    have to be deleted and that will result in one index scan
    over computer and 2000 index scans for the software. The
-    rule implementation will do it with two queries over indices.
+    rule implementation will do it with two queries over indexes.
    And it depends on the overall size of the software table if
    the rule will still be faster in the seqscan situation. 2000
    query executions over the SPI manager take some time, even

--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.6 2001/05/15 13:57:37 momjian Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v 1.7 2001/05/17 21:50:16 petere Exp $ -->
 <chapter id="wal">
 <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@@ -18,7 +18,7 @@
   is a standard approach to transaction logging.  Its detailed
   description may be found in most (if not all) books about
   transaction processing. Briefly, <acronym>WAL</acronym>'s central
-   concept is that changes to data files (where tables and indices
+   concept is that changes to data files (where tables and indexes
   reside) must be written only after those changes have been logged -
   that is, when log records have been flushed to permanent
   storage. When we follow this procedure, we do not need to flush
@@ -67,7 +67,7 @@
     </listitem>
    </orderedlist>
-    Problems with indices (problems 1 and 2) could possibly have been
+    Problems with indexes (problems 1 and 2) could possibly have been
    fixed by additional <function>fsync()</function> calls, but it is
    not obvious how to handle the last case without
    <acronym>WAL</acronym>; <acronym>WAL</acronym> saves the entire

--- a/doc/src/sgml/xindex.sgml
+++ b/doc/src/sgml/xindex.sgml
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.14 2001/03/24 23:03:26 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.15 2001/05/17 21:50:17 petere Exp $
 Postgres documentation
 -->
 <chapter id="xindex">
-  <title>Interfacing Extensions To Indices</title>
+  <title>Interfacing Extensions To Indexes</title>
  <para>
   The procedures described thus far let you define a new type, new
@@ -34,7 +34,7 @@ Postgres documentation
   <table tocentry="1">
    <title>Index Schema</title>
-    <titleabbrev>Indices</titleabbrev>
    <tgroup cols="2">
     <thead>
      <row>
@@ -118,7 +118,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
   example, that the  "&lt;="  and  "&gt;" operators partition a
   <acronym>B-tree</acronym>.  <productname>Postgres</productname>
   uses strategies to express these relationships  between
-   operators and the way they can be used to scan indices.
+   operators and the way they can be used to scan indexes.
  </para>
  <para>

--- a/doc/src/sgml/xtypes.sgml
+++ b/doc/src/sgml/xtypes.sgml
@@ -10,7 +10,7 @@
   As previously mentioned, there are two kinds  of  types
   in  <productname>Postgres</productname>: base types (defined in a programming language) 
   and composite types.
-   Examples in this section up to interfacing indices  can
+   Examples in this section up to interfacing indexes  can
   be  found in <filename>complex.sql</filename> and <filename>complex.c</filename>.  Composite examples 
   are in <filename>funcs.sql</filename>.
  </para>