Mark all GUC variables with <varname> markup, rather than <literal>.

Author: bmomjian

doc/src/sgml/datetime.sgml

@@ -360,10 +360,10 @@
    </para>
 
    <para>
-    <literal>timezone_abbreviations</> can be set to any file name
+    <varname>timezone_abbreviations</> can be set to any file name
     found in <filename>.../share/timezonesets/</>, if the file's name
     is entirely alphabetic.  (The prohibition against non-alphabetic
-    characters in <literal>timezone_abbreviations</> prevents reading
+    characters in <varname>timezone_abbreviations</> prevents reading
     files outside the intended directory, as well as reading editor
     backup files and other extraneous files.)
    </para>
@@ -420,7 +420,7 @@
     according to the <literal>zoneinfo</> timezone database.  The zone name
     definitions found in these files can be copied and pasted into a custom
     configuration file as needed.  Note that these files cannot be directly
-    referenced as <literal>timezone_abbreviations</> settings, because of
+    referenced as <varname>timezone_abbreviations</> settings, because of
     the dot embedded in their names.
    </para>
 

doc/src/sgml/libpq.sgml

@@ -1418,46 +1418,46 @@ const char *PQparameterStatus(const PGconn *conn, const char *paramName);
 
       <para>
        Parameters reported as of the current release include
-       <literal>server_version</>,
-       <literal>server_encoding</>,
-       <literal>client_encoding</>,
-       <literal>application_name</>,
-       <literal>is_superuser</>,
-       <literal>session_authorization</>,
-       <literal>DateStyle</>,
-       <literal>IntervalStyle</>,
-       <literal>TimeZone</>,
-       <literal>integer_datetimes</>, and
-       <literal>standard_conforming_strings</>.
-       (<literal>server_encoding</>, <literal>TimeZone</>, and
-       <literal>integer_datetimes</> were not reported by releases before 8.0;
-       <literal>standard_conforming_strings</> was not reported by releases
+       <varname>server_version</>,
+       <varname>server_encoding</>,
+       <varname>client_encoding</>,
+       <varname>application_name</>,
+       <varname>is_superuser</>,
+       <varname>session_authorization</>,
+       <varname>DateStyle</>,
+       <varname>IntervalStyle</>,
+       <varname>TimeZone</>,
+       <varname>integer_datetimes</>, and
+       <varname>standard_conforming_strings</>.
+       (<varname>server_encoding</>, <varname>TimeZone</>, and
+       <varname>integer_datetimes</> were not reported by releases before 8.0;
+       <varname>standard_conforming_strings</> was not reported by releases
        before 8.1;
-       <literal>IntervalStyle</> was not reported by releases before 8.4;
-       <literal>application_name</> was not reported by releases before 9.0.)
+       <varname>IntervalStyle</> was not reported by releases before 8.4;
+       <varname>application_name</> was not reported by releases before 9.0.)
        Note that
-       <literal>server_version</>,
-       <literal>server_encoding</> and
-       <literal>integer_datetimes</>
+       <varname>server_version</>,
+       <varname>server_encoding</> and
+       <varname>integer_datetimes</>
        cannot change after startup.
       </para>
 
       <para>
        Pre-3.0-protocol servers do not report parameter settings, but
        <application>libpq</> includes logic to obtain values for
-       <literal>server_version</> and <literal>client_encoding</> anyway.
+       <varname>server_version</> and <varname>client_encoding</> anyway.
        Applications are encouraged to use <function>PQparameterStatus</>
        rather than <foreignphrase>ad hoc</> code to determine these values.
        (Beware however that on a pre-3.0 connection, changing
-       <literal>client_encoding</> via <command>SET</> after connection
+       <varname>client_encoding</> via <command>SET</> after connection
        startup will not be reflected by <function>PQparameterStatus</>.)
-       For <literal>server_version</>, see also
+       For <varname>server_version</>, see also
        <function>PQserverVersion</>, which returns the information in a
        numeric form that is much easier to compare against.
       </para>
 
       <para>
-       If no value for <literal>standard_conforming_strings</> is reported,
+       If no value for <varname>standard_conforming_strings</> is reported,
        applications can assume it is <literal>off</>, that is, backslashes
        are treated as escapes in string literals.  Also, the presence of
        this parameter can be taken as an indication that the escape string

doc/src/sgml/maintenance.sgml

@@ -670,13 +670,13 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
     autovacuum will only touch the table if it must do so
     to prevent transaction ID wraparound.
     Another two parameters,
-    <literal>autovacuum_vacuum_cost_delay</literal> and
-    <literal>autovacuum_vacuum_cost_limit</literal>, are used to set
+    <varname>autovacuum_vacuum_cost_delay</> and
+    <varname>autovacuum_vacuum_cost_limit</>, are used to set
     table-specific values for the cost-based vacuum delay feature
     (see <xref linkend="runtime-config-resource-vacuum-cost">).
-    <literal>autovacuum_freeze_min_age</literal>,
-    <literal>autovacuum_freeze_max_age</literal> and
-    <literal>autovacuum_freeze_table_age</literal> are used to set
+    <varname>autovacuum_freeze_min_age</>,
+    <varname>autovacuum_freeze_max_age</> and
+    <varname>autovacuum_freeze_table_age</> are used to set
     values for <xref linkend="guc-vacuum-freeze-min-age">,
     <xref linkend="guc-autovacuum-freeze-max-age"> and
     <xref linkend="guc-vacuum-freeze-table-age"> respectively.
@@ -764,7 +764,7 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
    A better approach is to send the server's
    <systemitem>stderr</> output to some type of log rotation program.
    There is a built-in log rotation facility, which you can use by
-   setting the configuration parameter <literal>logging_collector</> to
+   setting the configuration parameter <varname>logging_collector</> to
    <literal>true</> in <filename>postgresql.conf</>.  The control
    parameters for this program are described in <xref
    linkend="runtime-config-logging-where">. You can also use this approach
@@ -794,7 +794,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
    Another production-grade approach to managing log output is to
    send it to <application>syslog</> and let
    <application>syslog</> deal with file rotation. To do this, set the
-   configuration parameter <literal>log_destination</> to <literal>syslog</>
+   configuration parameter <varname>log_destination</> to <literal>syslog</>
    (to log to <application>syslog</> only) in
    <filename>postgresql.conf</>. Then you can send a <literal>SIGHUP</literal>
    signal to the <application>syslog</> daemon whenever you want to force it

doc/src/sgml/pgarchivecleanup.sgml

@@ -111,7 +111,7 @@ pg_archivecleanup:  removing file "archive/00000001000000370000000E"
 archive_cleanup_command = 'pg_archivecleanup -d /mnt/standby/archive %r 2>>cleanup.log'
 </programlisting>
    where the archive directory is physically located on the standby server,
-   so that the <literal>archive_command</> is accessing it across NFS,
+   so that the <varname>archive_command</> is accessing it across NFS,
    but the files are local to the standby.
    This will:
   </para>

doc/src/sgml/pgstandby.sgml

@@ -15,7 +15,7 @@
 
  <para>
   <application>pg_standby</> is designed to be a waiting
-  <literal>restore_command</literal>, which is needed to turn a standard
+  <varname>restore_command</>, which is needed to turn a standard
   archive recovery into a warm standby operation.  Other
   configuration is required as well, all of which is described in the main
   server manual (see <xref linkend="warm-standby">).
@@ -61,7 +61,7 @@ restore_command = 'pg_standby <replaceable>archiveDir</> %f %p %r'
 <synopsis>
 pg_standby <optional> <replaceable>option</> ... </optional> <replaceable>archivelocation</> <replaceable>nextwalfile</> <replaceable>xlogfilepath</> <optional> <replaceable>restartwalfile</> </optional>
 </synopsis>
-   When used within <literal>restore_command</literal>, the <literal>%f</> and
+   When used within <varname>restore_command</>, the <literal>%f</> and
    <literal>%p</> macros should be specified for <replaceable>nextwalfile</>
    and <replaceable>xlogfilepath</> respectively, to provide the actual file
    and path required for the restore.
@@ -241,7 +241,7 @@ restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f
 recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
 </programlisting>
    where the archive directory is physically located on the standby server,
-   so that the <literal>archive_command</> is accessing it across NFS,
+   so that the <varname>archive_command</> is accessing it across NFS,
    but the files are local to the standby (enabling use of <literal>ln</>).
    This will:
   <itemizedlist>
@@ -285,8 +285,8 @@ restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p
 recovery_end_command = 'del C:\pgsql.trigger.5442'
 </programlisting>
    Note that backslashes need to be doubled in the
-   <literal>archive_command</>, but <emphasis>not</emphasis> in the
-   <literal>restore_command</> or <literal>recovery_end_command</>.
+   <varname>archive_command</>, but <emphasis>not</emphasis> in the
+   <varname>restore_command</> or <varname>recovery_end_command</>.
    This will:
   <itemizedlist>
    <listitem>
@@ -357,7 +357,7 @@ recovery_end_command = 'del C:\pgsql.trigger.5442'
   </para>
   <para>
    <productname>PostgreSQL</> 8.4 provides the
-   <literal>recovery_end_command</literal> option.  Without this option
+   <varname>recovery_end_command</> option.  Without this option
    a leftover trigger file can be hazardous.
   </para>
  </sect2>

doc/src/sgml/protocol.sgml

@@ -1092,27 +1092,27 @@
    <para>
     At present there is a hard-wired set of parameters for which
     ParameterStatus will be generated: they are
-    <literal>server_version</>,
-    <literal>server_encoding</>,
-    <literal>client_encoding</>,
-    <literal>application_name</>,
-    <literal>is_superuser</>,
-    <literal>session_authorization</>,
-    <literal>DateStyle</>,
-    <literal>IntervalStyle</>,
-    <literal>TimeZone</>,
-    <literal>integer_datetimes</>, and
-    <literal>standard_conforming_strings</>.
-    (<literal>server_encoding</>, <literal>TimeZone</>, and
-    <literal>integer_datetimes</> were not reported by releases before 8.0;
-    <literal>standard_conforming_strings</> was not reported by releases
+    <varname>server_version</>,
+    <varname>server_encoding</>,
+    <varname>client_encoding</>,
+    <varname>application_name</>,
+    <varname>is_superuser</>,
+    <varname>session_authorization</>,
+    <varname>DateStyle</>,
+    <varname>IntervalStyle</>,
+    <varname>TimeZone</>,
+    <varname>integer_datetimes</>, and
+    <varname>standard_conforming_strings</>.
+    (<varname>server_encoding</>, <varname>TimeZone</>, and
+    <varname>integer_datetimes</> were not reported by releases before 8.0;
+    <varname>standard_conforming_strings</> was not reported by releases
     before 8.1;
-    <literal>IntervalStyle</> was not reported by releases before 8.4;
-    <literal>application_name</> was not reported by releases before 9.0.)
+    <varname>IntervalStyle</> was not reported by releases before 8.4;
+    <varname>application_name</> was not reported by releases before 9.0.)
     Note that
-    <literal>server_version</>,
-    <literal>server_encoding</> and
-    <literal>integer_datetimes</>
+    <varname>server_version</>,
+    <varname>server_encoding</> and
+    <varname>integer_datetimes</>
     are pseudo-parameters that cannot change after startup.
     This set might change in the future, or even become configurable.
     Accordingly, a frontend should simply ignore ParameterStatus for

doc/src/sgml/ref/pg_dump.sgml

@@ -864,7 +864,7 @@ PostgreSQL documentation
   <para>
    The database activity of <application>pg_dump</application> is
    normally collected by the statistics collector.  If this is
-   undesirable, you can set parameter <literal>track_counts</literal>
+   undesirable, you can set parameter <varname>track_counts</>
    to false via <envar>PGOPTIONS</envar> or the <literal>ALTER
    USER</literal> command.
   </para>