This patch makes some improvements and adds some additional detail

to the documentation on routine database maintainence activities.
I also corrected a bunch of SGML markup.

doc/src/sgml/page.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/page.sgml,v 1.16 2003/11/29 19:51:37 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/page.sgml,v 1.17 2003/12/14 00:10:32 neilc Exp $
 -->
 
 <chapter id="page">
@@ -151,7 +151,8 @@ data. Empty in ordinary tables.</entry>
  </table>
 
  <para>
-  All the details may be found in src/include/storage/bufpage.h.
+  All the details may be found in
+  <filename>src/include/storage/bufpage.h</filename>.
  </para>
 
  <para>  
@@ -305,7 +306,8 @@ data. Empty in ordinary tables.</entry>
  </table>
 
  <para>
-   All the details may be found in src/include/access/htup.h.
+   All the details may be found in
+   <filename>src/include/access/htup.h</filename>.
  </para>
 
  <para>

doc/src/sgml/perform.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.38 2003/11/29 19:51:37 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.39 2003/12/14 00:10:32 neilc Exp $
 -->
 
  <chapter id="performance-tips">
@@ -100,7 +100,7 @@ $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.38 2003/11/29 19:51:37 pgsql Ex
 
    <para>
     Here are some examples (using the regression test database after a
-    <literal>VACUUM ANALYZE</>, and 7.3 development sources):
+    <command>VACUUM ANALYZE</>, and 7.3 development sources):
 
 <programlisting>
 EXPLAIN SELECT * FROM tenk1;

doc/src/sgml/plperl.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.21 2003/11/29 19:51:37 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.22 2003/12/14 00:10:32 neilc Exp $
 -->
 
  <chapter id="plperl">
@@ -152,7 +152,7 @@ SELECT name, empcomp(employee) FROM employee;
   <para>
    The argument values supplied to a PL/Perl function's code are
    simply the input arguments converted to text form (just as if they
-   had been displayed by a <literal>SELECT</literal> statement).
+   had been displayed by a <command>SELECT</command> statement).
    Conversely, the <literal>return</> command will accept any string
    that is acceptable input format for the function's declared return
    type.  So, the PL/Perl programmer can manipulate data values as if

doc/src/sgml/typeconv.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.41 2003/12/02 00:26:59 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.42 2003/12/14 00:10:32 neilc Exp $
 -->
 
 <chapter Id="typeconv">
@@ -122,9 +122,9 @@ with, and perhaps converted to, the types of the target columns.
 </term>
 <listitem>
 <para>
-Since all query results from a unionized <literal>SELECT</literal> statement
+Since all query results from a unionized <command>SELECT</command> statement
 must appear in a single set of columns, the types of the results of each
-<literal>SELECT</> clause must be matched up and converted to a uniform set.
+<command>SELECT</> clause must be matched up and converted to a uniform set.
 Similarly, the branch expressions of a <literal>CASE</> construct must be
 converted to a common type so that the <literal>CASE</> expression as a whole
 has a known output type.  The same holds for <literal>ARRAY</> constructs.