Markup additions and spell check. (covers User's Guide)

doc/src/sgml/array.sgml

-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.11 2001/05/12 22:51:34 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/array.sgml,v 1.12 2001/09/09 17:21:44 petere Exp $ -->
 
 <chapter id="arrays">
  <title>Arrays</title>
@@ -9,7 +9,7 @@
 
  <para>
   <productname>Postgres</productname> allows columns of a table to be
-  defined as variable-length multi-dimensional arrays. Arrays of any
+  defined as variable-length multidimensional arrays. Arrays of any
   built-in type or user-defined type can be created.  To illustrate
   their use, we create this table:
 <programlisting>

doc/src/sgml/datetime.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.19 2001/06/18 19:05:11 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/datetime.sgml,v 2.20 2001/09/09 17:21:58 petere Exp $
 Date/time details
 -->
 
@@ -225,7 +225,7 @@ Date/time details
       <row>
        <entry>DNT</entry>
        <entry>+1:00 </entry>
-       <entry>Dansk Normal Tid</entry>
+       <entry><foreignphrase>Dansk Normal Tid</foreignphrase></entry>
       </row>
       <row>
        <entry>FST</entry>

doc/src/sgml/history.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
 -->
 
 <sect1 id="history">
@@ -13,7 +13,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
   California at Berkeley.  With over a decade of
   development behind it, <productname>PostgreSQL</productname> 
   is the most advanced open-source database available anywhere,
-  offering multi-version concurrency control, supporting almost
+  offering multiversion concurrency control, supporting almost
   all SQL constructs (including subselects, transactions, and
   user-defined types and functions), and having a wide range of
   language bindings available (including C, C++, Java, Perl, Tcl, and Python).
@@ -72,7 +72,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
    Finally,  
    <ulink url="http://www.illustra.com/">Illustra  Information  Technologies</ulink>
    (since merged into
-   <ulink url="http://www.informix.com/">Informix</ulink>)
+   <ulink url="http://www.informix.com/"><productname>Informix</productname></ulink>)
    picked up
    the code and commercialized it.
    <productname>Postgres</productname>  became  the  primary  data  manager
@@ -141,7 +141,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
      <para>
       A new  front-end  library,  <filename>libpgtcl</filename>,
       supported  <acronym>Tcl</acronym>-based  clients.   A sample shell, 
-      pgtclsh, provided new Tcl  commands  to  interface
+      <command>pgtclsh</command>, provided new Tcl  commands  to  interface
       <application>tcl</application>
       programs with the <productname>Postgres95</productname> backend.
      </para>
@@ -211,7 +211,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/history.sgml,v 1.13 2001/02/03 19:03:26 pet
   <itemizedlist>
    <listitem>
     <para>
-     Table-level locking has been replaced with multi-version concurrency control,
+     Table-level locking has been replaced with multiversion concurrency control,
      which allows readers to continue reading consistent data during writer activity
      and enables hot backups from pg_dump while the database stays available for
      queries.

doc/src/sgml/indices.sgml

-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.22 2001/08/24 14:07:48 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/indices.sgml,v 1.23 2001/09/09 17:21:59 petere Exp $ -->
 
 <chapter id="indexes">
  <title id="indexes-title">Indexes</title>
@@ -571,7 +571,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
     retrieving by that combination! However, if you want to make the retrieval
     efficient, you'll have to resort to the means your
     <acronym>RDBMS</acronym> provider gives you
-    - be it an index, my imaginary MEMSTORE command, or an intelligent
+    - be it an index, my imaginary <literal>MEMSTORE</literal> command, or an intelligent
     <acronym>RDBMS</acronym>
     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
@@ -629,7 +629,7 @@ CREATE MEMSTORE ON <replaceable>table</replaceable> COLUMNS <replaceable>cols</r
     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
-    problems, albeit with different cost parameters and formulae.  These
+    problems, albeit with different cost parameters and formulas.  These
     are, in the general case, hard problems for the standard ordinal 
     <acronym>SQL</acronym>
     types; they're super-hard problems with black-box extension types,

doc/src/sgml/inherit.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.13 2001/01/13 23:58:55 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
 -->
 
  <chapter id="inherit">
@@ -37,7 +37,7 @@ CREATE TABLE capitals (
 
    <note>
     <para>
-     The inheritance hierarchy is a actually a directed acyclic graph.
+     The inheritance hierarchy is actually a directed acyclic graph.
     </para>
    </note>
   </para>
@@ -100,7 +100,7 @@ SELECT name, altitude
   <para>
   In some cases you may wish to know which table a particular tuple
   originated from. There is a system column called
-  <quote>TABLEOID</quote> in each table which can tell you the
+  <structfield>TABLEOID</structfield> in each table which can tell you the
   originating table:
 
    <programlisting>

doc/src/sgml/legal.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.11 2001/09/09 17:21:59 petere Exp $
 -->
 
 <copyright>
@@ -42,7 +42,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/legal.sgml,v 1.10 2001/02/03 19:03:27 peter
   INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
   MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE
   PROVIDED HEREUNDER IS ON AN "AS-IS" BASIS, AND THE UNIVERSITY OF
-  CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTAINANCE, SUPPORT,
+  CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
   UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
  </para>
 

doc/src/sgml/manage.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.13 2001/02/04 15:28:18 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/manage.sgml,v 1.14 2001/09/09 17:21:59 petere Exp $
 -->
 
  <Chapter Id="manage">
   <Title>Managing a Database</Title>
 
-  <Note>
-   <Para>
-    This section is currently a thinly disguised copy of the
-    Tutorial. Needs to be augmented.
+  <comment>
+   This section is currently a thinly disguised copy of the
+   Tutorial. Needs to be augmented.
     - thomas 1998-01-12
-   </Para>
-  </Note>
+  </comment>
 
   <Para>
    Although the <FirstTerm>site administrator</FirstTerm> is responsible for overall management 
@@ -89,9 +87,9 @@ ERROR:  CREATE DATABASE: Permission denied.
     Alternate database locations are created and referenced by an environment variable 
     which gives the absolute path to the intended storage location.  
     This environment variable must have been defined before the postmaster was started 
-    and the location it points to must be writable by the postgres administrator account.
+    and the location it points to must be writable by the administrator account.
     Consult with the site administrator
-    regarding preconfigured alternate database locations.  
+    regarding preconfigured alternative database locations.  
     Any valid environment variable name may be used to reference an alternate location, 
     although using variable names with a prefix of <envar>PGDATA</envar> is recommended 
     to avoid confusion 
@@ -101,7 +99,7 @@ ERROR:  CREATE DATABASE: Permission denied.
    <Note>
     <Para>
      In previous versions of <ProductName>Postgres</ProductName>, 
-     it was also permissable to use an absolute path name to specify 
+     it was also permissible to use an absolute path name to specify 
      an alternate storage location.  
      Although the environment variable style of specification
      is to be preferred since it allows the site administrator more flexibility in
@@ -181,7 +179,7 @@ enter, edit, and execute <Acronym>SQL</Acronym> commands.
 </ListItem>
 <ListItem>
 <Para>
-      writing a  C  program  using  the  LIBPQ  subroutine
+      writing a  C  program  using  the  <application>LIBPQ</application> subroutine
         library.   This  allows  you  to submit <Acronym>SQL</Acronym> commands
         from C and get answers and status messages  back  to
         your  program.   This interface is discussed further
@@ -213,7 +211,7 @@ mydb=>
 </Para>
 
 <Para>
-This prompt indicates that psql is listening
+This prompt indicates that <command>psql</command> is listening
   to you and that you can type <Acronym>SQL</Acronym> queries into a
      workspace maintained by the terminal monitor.
      The <Application>psql</Application> program responds to escape  codes  that  begin
@@ -235,7 +233,7 @@ mydb=> \g
      terminate your query with a semicolon, the  "<literal>\g</literal>" is  not
      necessary.   
 <Application>psql</Application> will automatically process semicolon terminated queries.
-     To read queries from a file,  say  myFile,  instead  of
+     To read queries from a file,  say  <filename>myFile</filename>,  instead  of
      entering them interactively, type:
 <ProgramListing>
 mydb=> \i fileName
@@ -247,7 +245,7 @@ mydb=> \q
 </ProgramListing>
 
      and  <Application>psql</Application>  will  quit  and  return  you to your command
-     shell. (For more escape codes, type <Command>\?</Command> at  the  psql
+     shell. (For more escape codes, type <Command>\?</Command> at  the  <command>psql</command>
      prompt.)
      White  space  (i.e.,  spaces, tabs and newlines) may be
      used freely in <Acronym>SQL</Acronym> queries.  Single-line comments  are  denoted  by

doc/src/sgml/mvcc.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.16 2001/07/09 22:18:33 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.17 2001/09/09 17:21:59 petere Exp $
 -->
 
  <chapter id="mvcc">
@@ -593,7 +593,7 @@ ERROR:  Can't serialize access due to concurrent update
     <variablelist>
      <varlistentry>
       <term>
-       GiST and R-Tree indexes
+       <acronym>GiST</acronym> and R-Tree indexes
       </term>
       <listitem>
        <para>

doc/src/sgml/notation.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.15 2001/09/09 17:21:59 petere Exp $
 -->
 
 <sect1 id="notation">
@@ -38,10 +38,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
 
  <para>
   Examples will show commands executed from various accounts and programs.
-  Commands executed from a Unix shell may be preceeded with a dollar sign
+  Commands executed from a Unix shell may be preceded with a dollar sign
   (<quote><literal>$</literal></quote>).  Commands executed from particular user
-  accounts such as root or postgres are specially flagged and explained.
-  <acronym>SQL</acronym> commands may be preceeded with
+  accounts such as <systemitem>root</> or <systemitem>postgres</> are specially flagged and explained.
+  <acronym>SQL</acronym> commands may be preceded with
   <quote><literal>=&gt;</literal></quote>
   or will have no leading prompt, depending on the context.
  </para>
@@ -49,7 +49,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/notation.sgml,v 1.14 2001/02/03 19:03:27 pe
  <note>
   <para>
    The notation for
-   flagging commands is not universally consistant throughout the
+   flagging commands is not universally consistent throughout the
    documentation set.
    Please report problems to the documentation mailing list
    <email>pgsql-docs@postgresql.org</email>.

doc/src/sgml/perform.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.7 2001/06/22 18:53:36 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.8 2001/09/09 17:21:59 petere Exp $
 -->
 
  <chapter id="performance-tips">
@@ -109,9 +109,9 @@ Seq Scan on tenk1  (cost=0.00..333.00 rows=10000 width=148)
 select * from pg_class where relname = 'tenk1';
     </programlisting>
 
-    you'll find out that tenk1 has 233 disk
+    you will find out that <classname>tenk1</classname> has 233 disk
     pages and 10000 tuples.  So the cost is estimated at 233 page
-    reads, defined as 1.0 apiece, plus 10000 * cpu_tuple_cost which is
+    reads, defined as 1.0 apiece, plus 10000 * <varname>cpu_tuple_cost</varname> which is
     currently 0.01 (try <command>show cpu_tuple_cost</command>).
    </para>
 
@@ -152,7 +152,7 @@ Index Scan using tenk1_unique1 on tenk1  (cost=0.00..173.32 rows=47 width=148)
 
     and you will see that if we make the WHERE condition selective
     enough, the planner will
-    eventually decide that an indexscan is cheaper than a sequential scan.
+    eventually decide that an index scan is cheaper than a sequential scan.
     This plan will only have to visit 50 tuples because of the index,
     so it wins despite the fact that each individual fetch is more expensive
     than reading a whole disk page sequentially.
@@ -169,7 +169,7 @@ NOTICE:  QUERY PLAN:
 Index Scan using tenk1_unique1 on tenk1  (cost=0.00..173.44 rows=1 width=148)
     </programlisting>
 
-    The added clause "stringu1 = 'xxx'" reduces the output-rows estimate,
+    The added clause <literal>stringu1 = 'xxx'</literal> reduces the output-rows estimate,
     but not the cost because we still have to visit the same set of tuples.
    </para>
 
@@ -190,18 +190,18 @@ Nested Loop  (cost=0.00..269.11 rows=47 width=296)
    </para>
 
    <para>
-    In this nested-loop join, the outer scan is the same indexscan we had
+    In this nested-loop join, the outer scan is the same index scan we had
     in the example before last, and so its cost and row count are the same
     because we are applying the "unique1 &lt; 50" WHERE clause at that node.
     The "t1.unique2 = t2.unique2" clause isn't relevant yet, so it doesn't
-    affect the outer scan's row count.  For the inner scan, the
+    affect row count of the outer scan.  For the inner scan, the unique2 value of the
     current
-    outer-scan tuple's unique2 value is plugged into the inner indexscan
-    to produce an indexqual like
+    outer-scan tuple is plugged into the inner index scan
+    to produce an index qualification like
     "t2.unique2 = <replaceable>constant</replaceable>".  So we get the
-     same inner-scan plan and costs that we'd get from, say, "explain select
-     * from tenk2 where unique2 = 42".  The loop node's costs are then set
-     on the basis of the outer scan's cost, plus one repetition of the
+     same inner-scan plan and costs that we'd get from, say, <literal>explain select
+     * from tenk2 where unique2 = 42</literal>.  The costs of the loop node are then set
+     on the basis of the cost of the outer scan, plus one repetition of the
      inner scan for each outer tuple (47 * 2.01, here), plus a little CPU
      time for join processing.
    </para>
@@ -212,7 +212,7 @@ Nested Loop  (cost=0.00..269.11 rows=47 width=296)
     in general you can have WHERE clauses that mention both relations and
     so can only be applied at the join point, not to either input scan.
     For example, if we added "WHERE ... AND t1.hundred &lt; t2.hundred",
-    that'd decrease the output row count of the join node, but not change
+    that would decrease the output row count of the join node, but not change
     either input scan.
    </para>
 
@@ -237,13 +237,13 @@ Hash Join  (cost=173.44..557.03 rows=47 width=296)
                (cost=0.00..173.32 rows=47 width=148)
     </programlisting>
 
-    This plan proposes to extract the 50 interesting rows of tenk1
-    using ye same olde indexscan, stash them into an in-memory hash table,
-    and then do a sequential scan of tenk2, probing into the hash table
-    for possible matches of "t1.unique2 = t2.unique2" at each tenk2 tuple.
-    The cost to read tenk1 and set up the hash table is entirely start-up
+    This plan proposes to extract the 50 interesting rows of <classname>tenk1</classname>
+    using ye same olde index scan, stash them into an in-memory hash table,
+    and then do a sequential scan of <classname>tenk2</classname>, probing into the hash table
+    for possible matches of "t1.unique2 = t2.unique2" at each <classname>tenk2</classname> tuple.
+    The cost to read <classname>tenk1</classname> and set up the hash table is entirely start-up
     cost for the hash join, since we won't get any tuples out until we can
-    start reading tenk2.  The total time estimate for the join also
+    start reading <classname>tenk2</classname>.  The total time estimate for the join also
     includes a hefty charge for CPU time to probe the hash table
     10000 times.  Note, however, that we are NOT charging 10000 times 173.32;
     the hash table setup is only done once in this plan type.
@@ -302,8 +302,8 @@ SELECT * FROM a,b,c WHERE a.id = b.id AND b.ref = c.id;
    annoyingly long time.  When there are too many input tables, the
    <productname>Postgres</productname> planner will switch from exhaustive
    search to a <firstterm>genetic</firstterm> probabilistic search
-   through a limited number of possibilities.  (The switchover threshold is
-   set by the GEQO_THRESHOLD run-time
+   through a limited number of possibilities.  (The switch-over threshold is
+   set by the <varname>GEQO_THRESHOLD</varname> run-time
    parameter described in the <citetitle>Administrator's Guide</citetitle>.)
    The genetic search takes less time, but it won't
    necessarily find the best possible plan.

doc/src/sgml/problems.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.8 2001/09/09 17:21:59 petere Exp $
 -->
 
 <sect1 id="bug-reporting">
@@ -137,10 +137,10 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
       query.
       You are encouraged to
       minimize the size of your example, but this is not absolutely necessary.
-      If the bug is reproduceable, we will find it either way.
+      If the bug is reproducible, we will find it either way.
      </para>
      <para>
-      If your application uses some other client interface, such as PHP, then
+      If your application uses some other client interface, such as <applicatioN>PHP</>, then
       please try to isolate the offending queries. We will probably not set up a
       web server to reproduce your problem. In any case remember to provide
       the exact input files, do not guess that the problem happens for
@@ -174,7 +174,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
       The output you expected is very important to state. If you just write
       "This command gives me that output." or "This is not
       what I expected.", we might run it ourselves, scan the output, and
-      think it looks okay and is exactly what we expected. We should not have to
+      think it looks OK and is exactly what we expected. We should not have to
       spend the time to decode the exact semantics behind your commands.
       Especially refrain from merely saying that "This is not what SQL says/Oracle
       does." Digging out the correct behavior from <acronym>SQL</acronym>
@@ -188,7 +188,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
      <para>
       Any command line options and other start-up options, including concerned
       environment variables or configuration files that you changed from the
-      default. Again, be exact. If you are using a pre-packaged
+      default. Again, be exact. If you are using a prepackaged
       distribution that starts the database server at boot time, you should try
       to find out how that is done.
      </para>
@@ -212,7 +212,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/problems.sgml,v 2.7 2001/03/24 03:40:44 tgl
       old enough.  You can also look into the <filename>README</filename> file
       in the source directory or at the
       name of your distribution file or package name.
-      If you run a pre-packaged version, such as RPMs, say so, including any
+      If you run a prepackaged version, such as RPMs, say so, including any
       subversion the package may have. If you are talking about a CVS
       snapshot, mention that, including its date and time.
      </para>

doc/src/sgml/queries.sgml

-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.8 2001/08/30 08:16:42 ishii Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.9 2001/09/09 17:21:59 petere Exp $ -->
 
 <chapter id="queries">
  <title>Queries</title>
@@ -85,7 +85,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
     A table reference may be a table name or a derived table such as a
     subquery, a table join, or complex combinations of these.  If more
     than one table reference is listed in the FROM clause they are
-    CROSS JOINed (see below) to form the derived table that may then
+    cross-joined (see below) to form the derived table that may then
     be subject to transformations by the WHERE, GROUP BY, and HAVING
     clauses and is finally the result of the overall table expression.
    </para>
@@ -150,7 +150,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
      </varlistentry>
 
      <varlistentry>
-      <term>Qualified JOINs</term>
+      <term>Qualified joins</term>
       <listitem>
 
        <indexterm>
@@ -166,7 +166,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
         
        <para>
         The words <token>INNER</token> and <token>OUTER</token> are
-        optional for all JOINs.  <token>INNER</token> is the default;
+        optional for all joins.  <token>INNER</token> is the default;
         <token>LEFT</token>, <token>RIGHT</token>, and
         <token>FULL</token> imply an OUTER JOIN.
        </para>
@@ -281,7 +281,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
     <para>
      Joins of all types can be chained together or nested: either
      or both of <replaceable>T1</replaceable> and
-     <replaceable>T2</replaceable> may be JOINed tables.  Parentheses
+     <replaceable>T2</replaceable> may be joined tables.  Parentheses
      may be used around JOIN clauses to control the join order.  In the
      absence of parentheses, JOIN clauses nest left-to-right.
     </para>
@@ -479,7 +479,7 @@ FROM a NATURAL JOIN b WHERE b.val &gt; 5
      Which one of these you use is mainly a matter of style.  The JOIN
      syntax in the FROM clause is probably not as portable to other
      products.  For outer joins there is no choice in any case:  they
-     must be done in the FROM clause.  An outer join's ON/USING clause
+     must be done in the FROM clause.  A ON/USING clause of an outer join
      is <emphasis>not</> equivalent to a WHERE condition, because it
      determines the addition of rows (for unmatched input rows) as well
      as the removal of rows from the final result.
@@ -505,16 +505,18 @@ FROM FDT WHERE
 </programlisting>
 
    <para>
-    In the examples above, FDT is the table derived in the FROM
-    clause. Rows that do not meet the search condition of the where
-    clause are eliminated from FDT. Notice the use of scalar
-    subqueries as value expressions.  Just like
-    any other query, the subqueries can employ complex table
-    expressions.  Notice how FDT is referenced in the subqueries.
-    Qualifying C1 as FDT.C1 is only necessary if C1 is also the name of a
-    column in the derived input table of the subquery.  Qualifying the
-    column name adds clarity even when it is not needed.  This shows how
-    the column naming scope of an outer query extends into its inner queries.
+    In the examples above, <literal>FDT</literal> is the table derived
+    in the FROM clause. Rows that do not meet the search condition of
+    the where clause are eliminated from
+    <literal>FDT</literal>. Notice the use of scalar subqueries as
+    value expressions.  Just like any other query, the subqueries can
+    employ complex table expressions.  Notice how
+    <literal>FDT</literal> is referenced in the subqueries.
+    Qualifying <literal>C1</> as <literal>FDT.C1</> is only necessary
+    if <literal>C1</> is also the name of a column in the derived
+    input table of the subquery.  Qualifying the column name adds
+    clarity even when it is not needed.  This shows how the column
+    naming scope of an outer query extends into its inner queries.
    </para>
   </sect2>
 
@@ -569,7 +571,7 @@ SELECT pid, p.name, (sum(s.units) * p.price) AS sales
   FROM products p LEFT JOIN sales s USING ( pid )
   GROUP BY pid, p.name, p.price;
 </programlisting>
-    In this example, the columns pid, p.name, and p.price must be in
+    In this example, the columns <literal>pid</literal>, <literal>p.name</literal>, and <literal>p.price</literal> must be in
     the GROUP BY clause since they are referenced in the query select
     list.  The column s.units does not have to be in the GROUP BY list
     since it is only used in an aggregate expression
@@ -868,12 +870,12 @@ SELECT a, b FROM table1 ORDER BY a + b;
 SELECT a AS b FROM table1 ORDER BY a;
 </programlisting>
    But these extensions do not work in queries involving UNION, INTERSECT,
-   or EXCEPT, and are not portable to other DBMSes.
+   or EXCEPT, and are not portable to other <acronym>DBMS</acronym>.
   </para>
 
   <para>
-   Each column specification may be followed by an optional ASC or
-   DESC to set the sort direction.  ASC is default.  Ascending order
+   Each column specification may be followed by an optional <token>ASC</token> or
+   <token>DESC</token> to set the sort direction.  <token>ASC</token> is default.  Ascending order
    puts smaller values first, where <quote>smaller</quote> is defined
    in terms of the <literal>&lt;</literal> operator.  Similarly,
    descending order is determined with the <literal>&gt;</literal>

doc/src/sgml/syntax.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.45 2001/08/26 21:17:12 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.46 2001/09/09 17:21:59 petere Exp $
 -->
 
 <chapter id="sql-syntax">
@@ -462,7 +462,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
      <listitem>
       <para>
        "$" (dollar) cannot be a single-character operator, although it
-       can be part of a multi-character operator name.
+       can be part of a multiple-character operator name.
       </para>
      </listitem>
 
@@ -476,7 +476,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
 
      <listitem>
       <para>
-       A multi-character operator name cannot end in "+" or "-",
+       A multiple-character operator name cannot end in "+" or "-",
        unless the name also contains at least one of these characters:
 <literallayout>
 ~ ! @ # % ^ &amp; | ` ? $
@@ -600,7 +600,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
    <para>
     Alternatively, C-style block comments can be used:
 <programlisting>
-/* multi-line comment
+/* multiline comment
  * with nesting: /* nested block comment */
  */
 </programlisting>
@@ -634,7 +634,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
 
      <variablelist>
       <varlistentry>
-       <term>oid</term>
+       <term><structfield>oid</></term>
        <listitem>
 	<para>
 	 <indexterm>
@@ -649,20 +649,22 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
       </varlistentry>
 
       <varlistentry>
-      <term>tableoid</term>
+      <term><structfield>tableoid</></term>
        <listitem>
 	<para>
 	 The OID of the table containing this row.  This attribute is
 	 particularly handy for queries that select from inheritance
 	 hierarchies, since without it, it's difficult to tell which
-	 individual table a row came from.  The tableoid can be joined
-	 against the OID attribute of pg_class to obtain the table name.
+	 individual table a row came from.  The
+	 <structfield>tableoid</structfield> can be joined against the
+	 <structfield>oid</structfield> column of
+	 <classname>pg_class</classname> to obtain the table name.
 	</para>
        </listitem>
       </varlistentry>
 
       <varlistentry>
-       <term>xmin</term>
+       <term><structfield>xmin</></term>
        <listitem>
 	<para>
 	 The identity (transaction ID) of the inserting transaction for
@@ -673,7 +675,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
       </varlistentry>
 
       <varlistentry>
-      <term>cmin</term>
+      <term><structfield>cmin</></term>
        <listitem>
 	<para>
 	 The command identifier (starting at zero) within the inserting
@@ -683,7 +685,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
       </varlistentry>
 
       <varlistentry>
-      <term>xmax</term>
+      <term><structfield>xmax</></term>
        <listitem>
 	<para>
 	 The identity (transaction ID) of the deleting transaction,
@@ -696,7 +698,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
       </varlistentry>
 
       <varlistentry>
-      <term>cmax</term>
+      <term><structfield>cmax</></term>
        <listitem>
 	<para>
 	 The command identifier within the deleting transaction, or zero.
@@ -705,16 +707,16 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
       </varlistentry>
 
       <varlistentry>
-      <term>ctid</term>
+      <term><structfield>ctid</></term>
        <listitem>
 	<para>
 	 The tuple ID of the tuple within its table.  This is a pair
 	 (block number, tuple index within block) that identifies the
-	 physical location of the tuple.  Note that although the ctid
-	 can be used to locate the tuple very quickly, a row's ctid
+	 physical location of the tuple.  Note that although the <structfield>ctid</structfield>
+	 can be used to locate the tuple very quickly, a row's <structfield>ctid</structfield>
 	 will change each time it is updated or moved by <command>VACUUM
 	 FULL</>.
-	 Therefore ctid is useless as a long-term row identifier.
+	 Therefore <structfield>ctid</structfield> is useless as a long-term row identifier.
 	 The OID, or even better a user-defined serial number, should
 	 be used to identify logical rows.
 	</para>
@@ -731,9 +733,9 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
      Recommended practice when using OIDs for row identification is to create
      a unique index on the OID column of each table for which the OID will be
      used.  Never assume that OIDs are unique across tables; use the
-     combination of tableoid and row OID if you need a database-wide
+     combination of <structfield>tableoid</> and row OID if you need a database-wide
      identifier.  (Future releases of Postgres are likely to use a separate
-     OID counter for each table, so that tableoid <emphasis>must</> be
+     OID counter for each table, so that <structfield>tableoid</> <emphasis>must</> be
      included to arrive at a globally unique identifier.)
     </para>
 

doc/src/sgml/typeconv.sgml

@@ -150,8 +150,8 @@ extended user-defined types to use these same features transparently.
 <para>
 An additional heuristic is provided in the parser to allow better guesses
 at proper behavior for <acronym>SQL</acronym> standard types. There are
-several basic <firstterm>type categories</firstterm> defined: boolean,
-numeric, string, bitstring, datetime, timespan, geometric, network,
+several basic <firstterm>type categories</firstterm> defined: <type>boolean</type>,
+<type>numeric</type>, <type>string</type>, <type>bitstring</type>, <type>datetime</type>, <type>timespan</type>, <type>geometric</type>, <type>network</type>,
 and user-defined. Each category, with the exception of user-defined, has
 a <firstterm>preferred type</firstterm> which is preferentially selected
 when there is ambiguity.
@@ -273,7 +273,7 @@ If only one candidate remains, use it; else continue to the next step.
 </step>
 <step performance="required">
 <para>
-If any input arguments are "unknown", check the type categories accepted
+If any input arguments are <quote>unknown</quote>, check the type categories accepted
 at those argument positions by the remaining candidates.  At each position,
 select "string"
 category if any candidate accepts that category (this bias towards string
@@ -281,7 +281,7 @@ is appropriate since an unknown-type literal does look like a string).
 Otherwise, if all the remaining candidates accept the same type category,
 select that category; otherwise fail because
 the correct choice cannot be deduced without more clues.  Also note whether
-any of the candidates accept a preferred datatype within the selected category.
+any of the candidates accept a preferred data type within the selected category.
 Now discard operator candidates that do not accept the selected type category;
 furthermore, if any candidate accepts a preferred type at a given argument
 position, discard candidates that accept non-preferred types for that
@@ -391,7 +391,7 @@ tgl=> SELECT 'abc' || 'def' AS "Unspecified";
 In this case there is no initial hint for which type to use, since no types
 are specified in the query. So, the parser looks for all candidate operators
 and finds that there are candidates accepting both string-category and
-bitstring-category inputs.  Since string category is preferred when available,
+bit-string-category inputs.  Since string category is preferred when available,
 that category is selected, and then the 
 "preferred type" for strings, <type>text</type>, is used as the specific
 type to resolve the unknown literals to.
@@ -440,7 +440,7 @@ will try to oblige.
 
 <step performance="required">
 <para>
-Check for an exact match in the pg_proc system catalog.
+Check for an exact match in the <classname>pg_proc</classname> system catalog.
 (Cases involving <type>unknown</type> will never find a match at
 this step.)
 </para></step>
@@ -491,7 +491,7 @@ is appropriate since an unknown-type literal does look like a string).
 Otherwise, if all the remaining candidates accept the same type category,
 select that category; otherwise fail because
 the correct choice cannot be deduced without more clues.  Also note whether
-any of the candidates accept a preferred datatype within the selected category.
+any of the candidates accept a preferred data type within the selected category.
 Now discard operator candidates that do not accept the selected type category;
 furthermore, if any candidate accepts a preferred type at a given argument
 position, discard candidates that accept non-preferred types for that
@@ -512,10 +512,10 @@ then fail.
 If no best match could be identified, see whether the function call appears
 to be a trivial type coercion request.  This happens if the function call
 has just one argument and the function name is the same as the (internal)
-name of some datatype.  Furthermore, the function argument must be either
+name of some data type.  Furthermore, the function argument must be either
 an unknown-type literal or a type that is binary-compatible with the named
-datatype.  When these conditions are met, the function argument is coerced
-to the named datatype.
+data type.  When these conditions are met, the function argument is coerced
+to the named data type.
 </para>
 </step>
 </procedure>
@@ -527,7 +527,7 @@ to the named datatype.
 <title>Factorial Function</title>
 
 <para>
-There is only one factorial function defined in the pg_proc catalog.
+There is only one factorial function defined in the <classname>pg_proc</classname> catalog.
 So the following query automatically converts the <type>int2</type> argument
 to <type>int4</type>:
 
@@ -554,7 +554,7 @@ tgl=> select int4fac(int4(int2 '4'));
 <title>Substring Function</title>
 
 <para>
-There are two <function>substr</function> functions declared in pg_proc. However,
+There are two <function>substr</function> functions declared in <classname>pg_proc</classname>. However,
 only one takes two arguments, of types <type>text</type> and <type>int4</type>.
 </para>
 
@@ -679,8 +679,8 @@ tgl=> SELECT * FROM vv;
 What's really happened here is that the two unknown literals are resolved
 to text by default, allowing the <literal>||</literal> operator to be
 resolved as text concatenation.  Then the text result of the operator
-is coerced to varchar to match the target column type.  (But, since the
-parser knows that text and varchar are binary-compatible, this coercion
+is coerced to <type>varchar</type> to match the target column type.  (But, since the
+parser knows that text and <type>varchar</type> are binary-compatible, this coercion
 is implicit and does not insert any real function call.)  Finally, the
 sizing function <literal>varchar(varchar,int4)</literal> is found in the system
 catalogs and applied to the operator's result and the stored column length.