Refer to GUC variables using <xref> tags rather than <varname> tags,

where appropriate. Add "id" and "xreflabel" tags to the descriptions
of the GUC variables to facilitate this. Also make a few minor docs
cleanups.

doc/src/sgml/backup.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.37 2004/02/17 23:56:07 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.38 2004/03/09 16:57:46 neilc Exp $
 -->
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -156,8 +156,8 @@ pg_dump -h <replaceable>host1</> <replaceable>dbname</> | psql -h <replaceable>h
    <tip>
     <para>
     Restore performance can be improved by increasing the
-    configuration parameter <varname>maintenance_work_mem</varname>
-    (see <xref linkend="runtime-config-resource-memory">).
+    configuration parameter <xref
+    linkend="guc-maintenance-work-mem">.
     </para>
    </tip>
   </sect2>

doc/src/sgml/charset.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.42 2003/12/30 23:36:19 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/charset.sgml,v 2.43 2004/03/09 16:57:46 neilc Exp $ -->
 
 <chapter id="charset">
  <title>Localization</>
@@ -795,23 +795,23 @@ RESET client_encoding;
 
       <listitem>
        <para>
-	Using <envar>PGCLIENTENCODING</envar>.
-
-	If environment variable <envar>PGCLIENTENCODING</envar> is defined
-	in the client's environment, that client encoding is automatically
-	selected when a connection to the server is made.  (This can subsequently
-	be overridden using any of the other methods mentioned above.)
+        Using <envar>PGCLIENTENCODING</envar>. If environment variable
+        <envar>PGCLIENTENCODING</envar> is defined in the client's
+        environment, that client encoding is automatically selected
+        when a connection to the server is made.  (This can
+        subsequently be overridden using any of the other methods
+        mentioned above.)
        </para>
       </listitem>
 
       <listitem>
       <para>
-       Using the configuration variable <varname>client_encoding</varname>.
-
-      If the <varname>client_encoding</> variable in <filename>postgresql.conf</> is set, that
-      client encoding is automatically selected when a connection to the
-      server is made.  (This can subsequently be overridden using any of the
-      other methods mentioned above.)
+       Using the configuration variable <xref
+       linkend="guc-client-encoding">. If the
+       <varname>client_encoding</> variable is set, that client
+       encoding is automatically selected when a connection to the
+       server is made.  (This can subsequently be overridden using any
+       of the other methods mentioned above.)
        </para>
       </listitem>
 

doc/src/sgml/client-auth.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.63 2004/01/26 05:35:15 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.64 2004/03/09 16:57:46 neilc Exp $
 -->
 
 <chapter id="client-authentication">
@@ -113,8 +113,8 @@ hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>
       <para>
        This record matches connection attempts made using TCP/IP.
        Note that TCP/IP connections are disabled unless the server is
-       started with the <option>-i</option> option or the
-       <varname>tcpip_socket</> configuration parameter is
+       started with the <option>-i</option> option or the <xref
+       linkend="guc-tcpip-socket"> configuration parameter is
        enabled. <literal>host</literal> records match either
        <acronym>SSL</acronym> or non-<acronym>SSL</acronym> connection
        attempts.
@@ -134,8 +134,8 @@ hostnossl  <replaceable>database</replaceable>  <replaceable>user</replaceable>
       <para>
        To make use of this option the server must be built with
        <acronym>SSL</acronym> support enabled. Furthermore,
-       <acronym>SSL</acronym> must be enabled by setting the
-       <varname>ssl</varname> configuration parameter (see <xref
+       <acronym>SSL</acronym> must be enabled by setting the <xref
+       linkend="guc-ssl"> configuration parameter (see <xref
        linkend="ssl-tcp"> for more information).
       </para>
      </listitem>
@@ -677,14 +677,14 @@ local   db1,db2,@demodbs  all                                       md5
    </para>
 
    <para>
-    Make sure that your server key file is readable (and preferably only
-    readable) by the <productname>PostgreSQL</productname> server
-    account.  (See also <xref linkend="postgres-user">). The location of the
-    key file is specified with the <varname>krb_server_keyfile</> run-time
-    configuration parameter. (See also <xref
-    linkend="runtime-config">.) The default is <filename>/etc/srvtab</>
-    if you are using Kerberos 4 and
-    <filename>FILE:/usr/local/pgsql/etc/krb5.keytab</> (or whichever
+    Make sure that your server key file is readable (and preferably
+    only readable) by the <productname>PostgreSQL</productname> server
+    account.  (See also <xref linkend="postgres-user">). The location
+    of the key file is specified by the <xref
+    linkend="guc-krb-server-keyfile"> run-time configuration
+    parameter. (See also <xref linkend="runtime-config">.) The default
+    is <filename>/etc/srvtab</> if you are using Kerberos 4 and
+    <filename>/usr/local/pgsql/etc/krb5.keytab</> (or whichever
     directory was specified as <varname>sysconfdir</> at build time)
     with Kerberos 5.
    </para>

doc/src/sgml/datatype.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.142 2004/02/01 06:55:07 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.143 2004/03/09 16:57:46 neilc Exp $
 -->
 
  <chapter id="datatype">
@@ -1409,7 +1409,7 @@ SELECT b, char_length(b) FROM test2;
      traditional <productname>POSTGRES</productname>, and others.
      For some formats, ordering of month, day, and year in date input is
      ambiguous and there is support for specifying the expected
-     ordering of these fields.  Set the <varname>datestyle</> parameter
+     ordering of these fields.  Set the <xref linkend="guc-datestyle"> parameter
      to <literal>MDY</> to select month-day-year interpretation,
      <literal>DMY</> to select day-month-year interpretation, or
      <literal>YMD</> to select year-month-day interpretation.
@@ -1720,7 +1720,7 @@ January 8 04:05:06 1999 PST
       time zone specified is converted to UTC using the appropriate offset
       for that time zone.  If no time zone is stated in the input string,
       then it is assumed to be in the time zone indicated by the system's
-      <varname>timezone</> parameter, and is converted to UTC using the
+      <xref linkend="guc-timezone"> parameter, and is converted to UTC using the
       offset for the <varname>timezone</> zone.
      </para>
 
@@ -1993,8 +1993,8 @@ January 8 04:05:06 1999 PST
 
     <para>
      The date/time styles can be selected by the user using the
-     <command>SET datestyle</command> command, the
-     <varname>datestyle</varname> parameter in the
+     <command>SET datestyle</command> command, the <xref
+     linkend="guc-datestyle"> parameter in the
      <filename>postgresql.conf</filename> configuration file, or the
      <envar>PGDATESTYLE</envar> environment variable on the server or
      client.  The formatting function <function>to_char</function>
@@ -2092,8 +2092,8 @@ January 8 04:05:06 1999 PST
 
       <listitem>
        <para>
-        The <varname>timezone</varname> configuration parameter can be
-        set in the file <filename>postgresql.conf</>.
+        The <xref linkend="guc-timezone"> configuration parameter can
+        be set in the file <filename>postgresql.conf</>.
        </para>
       </listitem>
 
@@ -2929,7 +2929,7 @@ SELECT * FROM test;
     <productname>PostgreSQL</productname> as primary keys for various
     system tables.  An OID system column is also added to user-created
     tables, unless <literal>WITHOUT OIDS</literal> is specified when
-    the table is created, or the <varname>default_with_oids</varname>
+    the table is created, or the <xref linkend="guc-default-with-oids">
     configuration variable is set to false.  Type <type>oid</>
     represents an object identifier.  There are also several alias
     types for <type>oid</>: <type>regproc</>, <type>regprocedure</>,

doc/src/sgml/func.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.192 2004/03/07 01:01:44 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.193 2004/03/09 16:57:46 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -311,7 +311,7 @@ PostgreSQL documentation
     returns true if <replaceable>expression</replaceable> evaluates to
     the null value.  It is highly recommended that these applications
     be modified to comply with the SQL standard. However, if that
-    cannot be done the <varname>transform_null_equals</varname>
+    cannot be done the <xref linkend="guc-transform-null-equals">
     configuration variable is available. If it is enabled,
     <productname>PostgreSQL</productname> will convert <literal>x =
     NULL</literal> clauses to <literal>x IS NULL</literal>.  This was
@@ -2715,12 +2715,12 @@ substring('foobar' from 'o(.)b')   <lineannotation>o</lineannotation>
 
    <note>
     <para>
-     The form of regular expressions accepted by <productname>PostgreSQL</>
-     can be chosen by setting the <varname>regex_flavor</> run-time parameter
-     (described in <xref linkend="runtime-config">).  The usual setting is
-     <literal>advanced</>, but one might choose <literal>extended</> for
-     maximum backwards compatibility with pre-7.4 releases of
-     <productname>PostgreSQL</>.
+     The form of regular expressions accepted by
+     <productname>PostgreSQL</> can be chosen by setting the <xref
+     linkend="guc-regex-flavor"> run-time parameter.  The usual
+     setting is <literal>advanced</>, but one might choose
+     <literal>extended</> for maximum backwards compatibility with
+     pre-7.4 releases of <productname>PostgreSQL</>.
     </para>
    </note>
 

doc/src/sgml/perform.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.41 2004/02/03 17:34:02 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.42 2004/03/09 16:57:46 neilc Exp $
 -->
 
  <chapter id="performance-tips">
@@ -508,7 +508,7 @@ SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;
    <productname>PostgreSQL</productname> planner will switch from exhaustive
    search to a <firstterm>genetic</firstterm> probabilistic search
    through a limited number of possibilities.  (The switch-over threshold is
-   set by the <varname>geqo_threshold</varname> run-time
+   set by the <xref linkend="guc-geqo-threshold"> run-time
    parameter.)
    The genetic search takes less time, but it won't
    necessarily find the best possible plan.
@@ -549,7 +549,7 @@ SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);
 
   <para>
    To force the planner to follow the <literal>JOIN</> order for inner joins,
-   set the <varname>join_collapse_limit</> run-time parameter to 1.
+   set the <xref linkend="guc-join-collapse-limit"> run-time parameter to 1.
    (Other possible values are discussed below.)
   </para>
 
@@ -599,8 +599,8 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    problem replacing two separate three-way join problems.  Because of the
    exponential growth of the number of possibilities, this makes a big
    difference.  The planner tries to avoid getting stuck in huge join search
-   problems by not collapsing a subquery if more than
-   <varname>from_collapse_limit</> <literal>FROM</> items would result in the parent
+   problems by not collapsing a subquery if more than <xref linkend="guc-from-collapse-limit">
+   <literal>FROM</> items would result in the parent
    query.  You can trade off planning time against quality of plan by
    adjusting this run-time parameter up or down.
   </para>
@@ -688,11 +688,11 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    <title>Increase <varname>maintenance_work_mem</varname></title>
 
    <para>
-    Temporarily increasing the <varname>maintenance_work_mem</varname>
+    Temporarily increasing the <xref linkend="guc-maintenance-work-mem">
     configuration variable when restoring large amounts of data can
     lead to improved performance. This is because when a B-tree index
     is created from scratch, the existing content of the table needs
-    to be sorted. Allowing the merge sort to use more memory
+    to be sorted. Allowing the external merge sort to use more memory
     means that fewer merge passes will be required.  A larger setting for
     <varname>maintenance_work_mem</varname> may also speed up validation
     of foreign-key constraints.

doc/src/sgml/problems.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.17 2003/12/14 00:05:29 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.18 2004/03/09 16:57:46 neilc Exp $
 -->
 
 <sect1 id="bug-reporting">
@@ -173,7 +173,7 @@ $PostgreSQL: pgsql/doc/src/sgml/problems.sgml,v 2.17 2003/12/14 00:05:29 neilc E
        form of the message.  In <application>psql</>, say <literal>\set
        VERBOSITY verbose</> beforehand.  If you are extracting the message
        from the server log, set the run-time parameter
-       <varname>log_error_verbosity</> to <literal>verbose</> so that all
+       <xref linkend="guc-log-error-verbosity"> to <literal>verbose</> so that all
        details are logged.
       </para>
      </note>

doc/src/sgml/protocol.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.49 2003/12/14 00:10:32 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.50 2004/03/09 16:57:46 neilc Exp $ -->
 
 <chapter id="protocol">
  <title>Frontend/Backend Protocol</title>
@@ -390,12 +390,13 @@
       <ListItem>
        <Para>
         This message informs the frontend about the current (initial)
-	setting of backend parameters, such as <varname>client_encoding</>
-	or <varname>DateStyle</>.  The frontend may ignore this message,
-	or record the settings for its future use; see
-	<xref linkend="protocol-async"> for more detail.
-        The frontend should not respond to this message, but should
-        continue listening for a ReadyForQuery message.
+         setting of backend parameters, such as <xref
+          linkend="guc-client-encoding"> or <xref linkend="guc-datestyle">.
+         The frontend may ignore this message, or record the settings
+         for its future use; see <xref linkend="protocol-async"> for
+         more details.  The frontend should not respond to this
+         message, but should continue listening for a ReadyForQuery
+         message.
        </Para>
       </ListItem>
      </VarListEntry>

doc/src/sgml/ref/alter_table.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.65 2004/03/01 17:58:39 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/alter_table.sgml,v 1.66 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -123,6 +123,11 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
    </varlistentry>
 
    <varlistentry>
+    <indexterm>
+     <primary>TOAST</primary>
+     <secondary>per-column storage settings</secondary>
+    </indexterm>
+
     <term><literal>SET STORAGE</literal></term>
     <listitem>
      <para>
@@ -240,7 +245,7 @@ ALTER TABLE <replaceable class="PARAMETER">name</replaceable>
 	to be altered, but in the current version, this is the default
 	behavior.  (In releases before 7.1, <literal>ONLY</> was the
 	default behavior.  The default can be altered by changing the
-	configuration parameter <varname>sql_inheritance</varname>.)
+	configuration parameter <xref linkend="guc-sql-inheritance">.)
        </para>
       </listitem>
      </varlistentry>

doc/src/sgml/ref/analyze.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/analyze.sgml,v 1.18 2003/12/14 00:15:03 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/analyze.sgml,v 1.19 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -134,7 +134,7 @@ ANALYZE [ VERBOSE ] [ <replaceable class="PARAMETER">table</replaceable> [ (<rep
 
   <para>
    The extent of analysis can be controlled by adjusting the
-   <varname>default_statistics_target</varname> parameter variable, or
+   <xref linkend="guc-default-statistics-target"> configuration variable, or
    on a column-by-column basis by setting the per-column statistics
    target with <command>ALTER TABLE ... ALTER COLUMN ... SET
    STATISTICS</command> (see <xref linkend="sql-altertable"

doc/src/sgml/ref/checkpoint.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/checkpoint.sgml,v 1.11 2003/11/29 19:51:38 pgsql Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ref/checkpoint.sgml,v 1.12 2004/03/09 16:57:47 neilc Exp $ -->
 
 <refentry id="sql-checkpoint">
  <refmeta>
@@ -27,11 +27,11 @@ CHECKPOINT
   <para>
    Write-Ahead Logging (WAL) puts a checkpoint in the transaction log
    every so often. (To adjust the automatic checkpoint interval, see
-   the run-time
-   configuration options <varname>checkpoint_segments</varname>
-   and <varname>checkpoint_timeout</varname>.)
-   The <command>CHECKPOINT</command> command forces an immediate checkpoint
-   when the command is issued, without waiting for a scheduled checkpoint.
+   the run-time configuration options <xref linkend="guc-checkpoint-segments">
+   and <xref linkend="guc-checkpoint-timeout">.)  The
+   <command>CHECKPOINT</command> command forces an immediate
+   checkpoint when the command is issued, without waiting for a
+   scheduled checkpoint.
   </para>
 
   <para>

doc/src/sgml/ref/create_table.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.78 2004/03/01 17:58:39 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_table.sgml,v 1.79 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -249,7 +249,7 @@ and <replaceable class="PARAMETER">table_constraint</replaceable> is:
       should have OIDs (object identifiers) assigned to them.  If
       neither <literal>WITH OIDS</literal> nor <literal>WITHOUT
       OIDS</literal> is specified, the default value depends upon the
-      <varname>default_with_oids</varname> configuration parameter. (If
+      <xref linkend="guc-default-with-oids"> configuration parameter. (If
       the new table inherits from any tables that have OIDs, then
       <literal>WITH OIDS</> is forced even if the command says
       <literal>WITHOUT OIDS</>.)

doc/src/sgml/ref/create_table_as.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.20 2004/01/10 23:28:44 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_table_as.sgml,v 1.21 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -106,7 +106,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
        This optional clause specifies whether the table created by
        <command>CREATE TABLE AS</command> should include OIDs. If
        neither form of this clause if specified, the value of the
-       <varname>default_with_oids</varname> configuration parameter is
+       <xref linkend="guc-default-with-oids"> configuration parameter is
        used.
       </para>
      </listitem>
@@ -152,7 +152,7 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE <replaceable>table_name
    the <command>CREATE TABLE AS</command> command allows the user to
    explicitely specify whether OIDs should be included. If the
    presence of OIDs is not explicitely specified,
-   the <varname>default_with_oids</varname> configuration variable is
+   the <xref linkend="guc-default-with-oids"> configuration variable is
    used. While this variable currently defaults to true, the default
    value may be changed in the future. Therefore, applications that
    require OIDs in the table created by <command>CREATE TABLE

doc/src/sgml/ref/create_user.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/create_user.sgml,v 1.32 2003/12/14 00:15:03 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/create_user.sgml,v 1.33 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -98,7 +98,7 @@ where <replaceable class="PARAMETER">option</replaceable> can be:
 	These key words control whether the password is stored
 	encrypted in the system catalogs.  (If neither is specified,
 	the default behavior is determined by the configuration
-	parameter <varname>password_encryption</varname>.)  If the
+	parameter <xref linkend="guc-password-encryption">.)  If the
 	presented password string is already in MD5-encrypted format,
 	then it is stored encrypted as-is, regardless of whether
 	<literal>ENCRYPTED</> or <literal>UNENCRYPTED</> is specified

doc/src/sgml/ref/explain.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.32 2003/11/29 19:51:38 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/explain.sgml,v 1.33 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -100,8 +100,8 @@ ROLLBACK;
       than just a summary.  Usually this option is only useful for
       debugging <productname>PostgreSQL</productname>.  The
       <literal>VERBOSE</literal> output is either pretty-printed or
-      not, depending on the setting of the
-      <varname>explain_pretty_print</varname> configuration parameter.
+      not, depending on the setting of the <xref
+      linkend="guc-explain-pretty-print"> configuration parameter.
      </para>
     </listitem>
    </varlistentry>

doc/src/sgml/ref/postmaster.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.45 2004/02/03 17:34:02 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/postmaster.sgml,v 1.46 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -376,7 +376,7 @@ PostgreSQL documentation
 
     <listitem>
      <para>
-      Default value of the <varname>DateStyle</varname> run-time
+      Default value of the <xref linkend="guc-datestyle"> run-time
       parameter.  (The use of this environment variable is deprecated.)
      </para>
     </listitem>
@@ -429,10 +429,11 @@ PostgreSQL documentation
 
    <tip>
     <para>
-     You may be able to postpone reconfiguring your kernel by decreasing
-     <varname>shared_buffers</varname> to reduce the shared memory consumption
-     of <productname>PostgreSQL</>, and/or by reducing
-     <varname>max_connections</varname> to reduce the semaphore consumption.
+     You may be able to postpone reconfiguring your kernel by
+     decreasing <xref linkend="guc-shared-buffers"> to reduce the
+     shared memory consumption of <productname>PostgreSQL</>, and/or
+     by reducing <xref linkend="guc-max-connections"> to reduce the
+     semaphore consumption.
     </para>
    </tip>
 

doc/src/sgml/ref/select.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.75 2004/03/03 22:22:24 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.76 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -190,8 +190,8 @@ where <replaceable class="parameter">from_item</replaceable> can be one of:
         tables are to be scanned, but in the current version, this is
         the default behavior.  (In releases before 7.1,
         <literal>ONLY</> was the default behavior.)  The default
-        behavior can be modified by changing the
-        <varname>sql_interitance</varname> configuration option.
+        behavior can be modified by changing the <xref
+        linkend="guc-sql-inheritance"> configuration option.
        </para>
       </listitem>
      </varlistentry>
@@ -1023,7 +1023,7 @@ SELECT distributors.* FROM distributors d, distributors distributors;
     <command>SELECT</command> statement that also contains an explicit
     <literal>FROM</literal> clause.  Also, it is possible to disable
     the implicit-<literal>FROM</literal> feature by setting the
-    <varname>add_missing_from</> parameter to false.
+    <xref linkend="guc-add-missing-from"> parameter to false.
    </para>
   </refsect2>
 

doc/src/sgml/ref/select_into.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/select_into.sgml,v 1.27 2003/12/13 23:59:07 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/select_into.sgml,v 1.28 2004/03/09 16:57:47 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -103,7 +103,7 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replac
    rapidly incremented. As of <productname>PostgreSQL</> 7.5, the
    inclusion of OIDs in the table created by <command>SELECT
    INTO</command> is controlled by the
-   <varname>default_with_oids</varname> configuration variable. This
+   <xref linkend="guc-default-with-oids"> configuration variable. This
    variable currently defaults to true, but will likely default to
    false in a future release of <productname>PostgreSQL</>.
   </para>

doc/src/sgml/wal.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.27 2004/01/06 17:26:23 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.28 2004/03/09 16:57:47 neilc Exp $ -->
 
 <chapter id="wal">
  <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@@ -162,10 +162,10 @@
   </para>
 
   <para>
-   The server spawns a special process every so often
-   to create the next checkpoint.  A checkpoint is created every
-   <varname>checkpoint_segments</varname> log segments, or every
-   <varname>checkpoint_timeout</varname> seconds, whichever comes first.
+   The server spawns a special process every so often to create the
+   next checkpoint.  A checkpoint is created every <xref
+   linkend="guc-checkpoint-segments"> log segments, or every <xref
+   linkend="guc-checkpoint-timeout"> seconds, whichever comes first.
    The default settings are 3 segments and 300 seconds respectively.
    It is also possible to force a checkpoint by using the SQL command
    <command>CHECKPOINT</command>.
@@ -204,11 +204,11 @@
    space for the new record, <function>LogInsert</function> will have
    to write (move to kernel cache) a few filled <acronym>WAL</acronym>
    buffers. This is undesirable because <function>LogInsert</function>
-   is used on every database low level modification (for example,
-   row insertion) at a time when an exclusive lock is held on
-   affected data pages, so the operation needs to be as fast as
-   possible.  What is worse, writing <acronym>WAL</acronym> buffers may
-   also force the creation of a new log segment, which takes even more
+   is used on every database low level modification (for example, row
+   insertion) at a time when an exclusive lock is held on affected
+   data pages, so the operation needs to be as fast as possible.  What
+   is worse, writing <acronym>WAL</acronym> buffers may also force the
+   creation of a new log segment, which takes even more
    time. Normally, <acronym>WAL</acronym> buffers should be written
    and flushed by a <function>LogFlush</function> request, which is
    made, for the most part, at transaction commit time to ensure that
@@ -217,9 +217,9 @@
    not occur often enough to prevent <acronym>WAL</acronym> buffers
    being written by <function>LogInsert</function>. On such systems
    one should increase the number of <acronym>WAL</acronym> buffers by
-   modifying the configuration parameter <varname>wal_buffers</varname>.
-   The default number of <acronym>
-   WAL</acronym> buffers is 8.  Increasing this value will 
+   modifying the configuration parameter <xref
+   linkend="guc-wal-buffers">.  The default number of <acronym>
+   WAL</acronym> buffers is 8.  Increasing this value will
    correspondingly increase shared memory usage.
   </para>
 
@@ -228,20 +228,20 @@
    buffers to disk using the operating system <literal>sync()</> call.
    Busy servers may fill checkpoint segment files too quickly,
    causing excessive checkpointing. If such forced checkpoints happen
-   more frequently than <varname>checkpoint_warning</varname> seconds, 
+   more frequently than <xref linkend="guc-checkpoint-warning"> seconds, 
    a message, will be output to the server logs recommending increasing 
    <varname>checkpoint_segments</varname>.
   </para>
 
   <para>
-   The <varname>commit_delay</varname> parameter defines for how many
+   The <xref linkend="guc-commit-delay"> parameter defines for how many
    microseconds the server process will sleep after writing a commit
    record to the log with <function>LogInsert</function> but before
    performing a <function>LogFlush</function>. This delay allows other
    server processes to add their commit records to the log so as to have all
    of them flushed with a single log sync. No sleep will occur if
-   <varname>fsync</varname>
-   is not enabled, nor if fewer than <varname>commit_siblings</varname>
+   <xref linkend="guc-fsync">
+   is not enabled, nor if fewer than <xref linkend="guc-commit-siblings">
    other sessions are currently in active transactions; this avoids
    sleeping when it's unlikely that any other session will commit soon.
    Note that on most platforms, the resolution of a sleep request is
@@ -252,7 +252,7 @@
   </para>
 
   <para>
-   The <varname>wal_sync_method</varname> parameter determines how
+   The <xref linkend="guc-wal-sync-method"> parameter determines how
    <productname>PostgreSQL</productname> will ask the kernel to force
     <acronym>WAL</acronym> updates out to disk. 
    All the options should be the same as far as reliability goes,
@@ -262,11 +262,12 @@
   </para>
 
   <para>
-   Enabling the <varname>wal_debug</varname> configuration parameter
-   will result in each <function>LogInsert</function> and
-   <function>LogFlush</function> <acronym>WAL</acronym> call being
-   logged to the server log. This option may be replaced by a more
-   general mechanism in the future.
+   Enabling the <xref linkend="guc-wal-debug"> configuration parameter
+   (provided that <productname>PostgreSQL</productname> has been
+   compiled with support for it) will result in each
+   <function>LogInsert</function> and <function>LogFlush</function>
+   <acronym>WAL</acronym> call being logged to the server log. This
+   option may be replaced by a more general mechanism in the future.
   </para>
  </sect1>
 

doc/src/sgml/xfunc.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.79 2003/11/29 19:51:38 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/xfunc.sgml,v 1.80 2004/03/09 16:57:47 neilc Exp $
 -->
 
  <sect1 id="xfunc">
@@ -738,7 +738,7 @@ CREATE FUNCTION square_root(double precision) RETURNS double precision
       <para>
        If the name does not contain a directory part, the file is
        searched for in the path specified by the configuration variable
-       <varname>dynamic_library_path</varname>.<indexterm><primary>dynamic_library_path</></>
+       <xref linkend="guc-dynamic-library-path">.<indexterm><primary>dynamic_library_path</></>
       </para>
      </listitem>