Fix indentation of verbatim block elements

Block elements with verbatim formatting (literallayout, programlisting, screen, synopsis) should be aligned at column 0 independent of the surrounding SGML, because whitespace is significant, and indenting them creates erratic whitespace in the output. The CSS stylesheets already take care of indenting the output. Assorted markup improvements to go along with it.

Fix indentation of verbatim block elements
Block elements with verbatim formatting (literallayout, programlisting, screen, synopsis) should be aligned at column 0 independent of the surrounding SGML, because whitespace is significant, and indenting them creates erratic whitespace in the output. The CSS stylesheets already take care of indenting the output. Assorted markup improvements to go along with it.
66424a28 · Peter Eisentraut · 984d56b8 · 66424a28 · 66424a28 · 66424a28
Commit 66424a28 authored Jul 29, 2010 by Peter Eisentraut
55 changed files
--- a/doc/src/sgml/auto-explain.sgml
+++ b/doc/src/sgml/auto-explain.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/auto-explain.sgml,v 1.8 2010/04/03 07:22:52 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/auto-explain.sgml,v 1.9 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="auto-explain">
 <title>auto_explain</title>
@@ -19,9 +19,9 @@
  The module provides no SQL-accessible functions.  To use it, simply
  load it into the server.  You can load it into an individual session:
-  <programlisting>
+<programlisting>
 LOAD 'auto_explain';
-  </programlisting>
+</programlisting>
  (You must be superuser to do that.)  More typical usage is to preload
  it into all sessions by including <literal>auto_explain</> in
@@ -163,32 +163,32 @@ LOAD 'auto_explain';
   <xref linkend="guc-custom-variable-classes">.  Typical usage might be:
  </para>
-  <programlisting>
+<programlisting>
 # postgresql.conf
 shared_preload_libraries = 'auto_explain'
 custom_variable_classes = 'auto_explain'
 auto_explain.log_min_duration = '3s'
-  </programlisting>
+</programlisting>
 </sect2>
 <sect2>
  <title>Example</title>
-  <programlisting>
+<programlisting>
-  postgres=# LOAD 'auto_explain';
+postgres=# LOAD 'auto_explain';
-  postgres=# SET auto_explain.log_min_duration = 0;
+postgres=# SET auto_explain.log_min_duration = 0;
-  postgres=# SELECT count(*)
+postgres=# SELECT count(*)
           FROM pg_class, pg_index
           WHERE oid = indrelid AND indisunique;
-  </programlisting>
+</programlisting>
  <para>
   This might produce log output such as:
  </para>
-  <programlisting><![CDATA[
+<screen><![CDATA[
-  LOG:  duration: 3.651 ms  plan:
+LOG:  duration: 3.651 ms  plan:
  Query Text: SELECT count(*)
              FROM pg_class, pg_index
              WHERE oid = indrelid AND indisunique;
@@ -200,8 +200,7 @@ auto_explain.log_min_duration = '3s'
                Buckets: 1024  Batches: 1  Memory Usage: 4kB
                ->  Seq Scan on pg_index  (cost=0.00..3.02 rows=92 width=4) (actual time=0.008..3.187 rows=92 loops=1)
                      Filter: indisunique
-]]>
+]]></screen>
-  </programlisting>
 </sect2>
 <sect2>

--- a/doc/src/sgml/citext.sgml
+++ b/doc/src/sgml/citext.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.4 2010/06/29 22:29:13 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/citext.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="citext">
 <title>citext</title>
@@ -22,9 +22,9 @@
   in <productname>PostgreSQL</> has been to use the <function>lower</>
   function when comparing values, for example
-  <programlisting>
+<programlisting>
-   SELECT * FROM tab WHERE lower(col) = LOWER(?);
+SELECT * FROM tab WHERE lower(col) = LOWER(?);
-  </programlisting>
+</programlisting>
  </para>
  <para>
@@ -74,20 +74,20 @@
  <para>
   Here's a simple example of usage:
-  <programlisting>
+<programlisting>
-   CREATE TABLE users (
+CREATE TABLE users (
    nick CITEXT PRIMARY KEY,
    pass TEXT   NOT NULL
-   );
+);
-   INSERT INTO users VALUES ( 'larry',  md5(random()::text) );
+INSERT INTO users VALUES ( 'larry',  md5(random()::text) );
-   INSERT INTO users VALUES ( 'Tom',    md5(random()::text) );
+INSERT INTO users VALUES ( 'Tom',    md5(random()::text) );
-   INSERT INTO users VALUES ( 'Damian', md5(random()::text) );
+INSERT INTO users VALUES ( 'Damian', md5(random()::text) );
-   INSERT INTO users VALUES ( 'NEAL',   md5(random()::text) );
+INSERT INTO users VALUES ( 'NEAL',   md5(random()::text) );
-   INSERT INTO users VALUES ( 'Bj&oslash;rn',  md5(random()::text) );
+INSERT INTO users VALUES ( 'Bj&oslash;rn',  md5(random()::text) );
-   SELECT * FROM users WHERE nick = 'Larry';
+SELECT * FROM users WHERE nick = 'Larry';
-  </programlisting>
+</programlisting>
   The <command>SELECT</> statement will return one tuple, even though
   the <structfield>nick</> column was set to <quote>larry</> and the query

--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.139 2010/06/29 22:29:13 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/client-auth.sgml,v 1.140 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="client-authentication">
 <title>Client Authentication</title>
@@ -1353,11 +1353,11 @@ omicron         bryanh                  guest1
     Since LDAP often uses commas and spaces to separate the different
     parts of a DN, it is often necessary to use double-quoted parameter
     values when configuring LDAP options, for example:
+<programlisting>
+ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
+</programlisting>
    </para>
   </note>
-    <synopsis>
-ldapserver=ldap.example.net ldapprefix="cn=" ldapsuffix=", dc=example, dc=net"
-    </synopsis>
  </sect2>

--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.301 2010/07/27 19:01:16 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.302 2010/07/29 19:34:40 petere Exp $ -->
 <chapter Id="runtime-config">
  <title>Server Configuration</title>
@@ -5808,29 +5808,20 @@ plruby.use_strict = true        # generates error: unknown class name
        type a count of the number of granted locks and waiting locks is
        also dumped as well as the totals.  An example of the log file output
        is shown here:
-       </para>
+<screen>
-       <para>
+LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
-        LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
-       </para>
+LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
-       <para>
-        LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
      wait(0) type(AccessShareLock)
+LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
-       </para>
-       <para>
-        LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
-       </para>
+LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
-       <para>
-        LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(INVALID)
-       </para>
+</screen>
-       <para>
        Details of the structure being dumped may be found in
        src/include/storage/lock.h
       </para>

--- a/doc/src/sgml/cube.sgml
+++ b/doc/src/sgml/cube.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.7 2009/12/08 20:08:30 mha Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/cube.sgml,v 1.8 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="cube">
 <title>cube</title>
@@ -98,47 +98,46 @@
  <para>
   The <filename>cube</> module includes a GiST index operator class for
   <type>cube</> values.
-   The operators supported by the GiST opclass include:
+   The operators supported by the GiST opclass are shown in <xref linkend="cube-gist-operators">.
  </para>
-  <itemizedlist>
+  <table id="cube-gist-operators">
-   <listitem>
+   <title>Cube GiST operators</title>
-    <programlisting>
+   <tgroup cols="2">
-a = b                 Same as
+    <thead>
-    </programlisting>
+     <row>
-    <para>
+      <entry>Operator</entry>
-     The cubes a and b are identical.
+      <entry>Description</entry>
-    </para>
+     </row>
-   </listitem>
+    </thead>
-   <listitem>
-    <programlisting>
+    <tbody>
-a &amp;&amp; b                Overlaps
+     <row>
-    </programlisting>
+      <entry><literal>a = b</></entry>
-    <para>
+      <entry>The cubes a and b are identical.</entry>
-     The cubes a and b overlap.
+     </row>
-    </para>
-   </listitem>
+     <row>
-   <listitem>
+      <entry><literal>a &amp;&amp; b</></entry>
-    <programlisting>
+      <entry>The cubes a and b overlap.</entry>
-a @&gt; b                Contains
+     </row>
-    </programlisting>
-    <para>
+     <row>
-     The cube a contains the cube b.
+      <entry><literal>a @&gt; b</></entry>
-    </para>
+      <entry>The cube a contains the cube b.</entry>
-   </listitem>
+     </row>
-   <listitem>
-  <programlisting>
+     <row>
-a &lt;@ b                Contained in
+      <entry><literal>a &lt;@ b</></entry>
-  </programlisting>
+      <entry>The cube a is contained in the cube b.</entry>
-    <para>
+     </row>
-     The cube a is contained in the cube b.
+    </tbody>
-    </para>
+   </tgroup>
-   </listitem>
+  </table>
-  </itemizedlist>
  <para>
-   (Before PostgreSQL 8.2, the containment operators @&gt; and &lt;@ were
+   (Before PostgreSQL 8.2, the containment operators <literal>@&gt;</> and <literal>&lt;@</> were
-   respectively called @ and ~.  These names are still available, but are
+   respectively called <literal>@</> and <literal>~</>.  These names are still available, but are
   deprecated and will eventually be retired.  Notice that the old names
   are reversed from the convention formerly followed by the core geometric
   datatypes!)
@@ -147,10 +146,28 @@ a &lt;@ b                Contained in
  <para>
   The standard B-tree operators are also provided, for example
-  <programlisting>
+   <informaltable>
-[a, b] &lt; [c, d]                Less than
+    <tgroup cols="2">
-[a, b] &gt; [c, d]                Greater than
+     <thead>
-  </programlisting>
+      <row>
+       <entry>Operator</entry>
+       <entry>Description</entry>
+      </row>
+     </thead>
+     <tbody>
+      <row>
+       <entry><literal>[a, b] &lt; [c, d]</literal></entry>
+       <entry>Less than</entry>
+      </row>
+      <row>
+       <entry><literal>[a, b] &gt; [c, d]</literal></entry>
+       <entry>Greater than</entry>
+      </row>
+     </tbody>
+    </tgroup>
+   </informaltable>
   These operators do not make a lot of sense for any practical
   purpose but sorting. These operators first compare (a) to (c),

--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.254 2010/07/27 19:01:16 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/datatype.sgml,v 1.255 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="datatype">
  <title>Data Types</title>
@@ -1584,21 +1584,21 @@ SELECT E'\\xDEADBEEF';
   <para>
    The <type>interval</type> type has an additional option, which is
    to restrict the set of stored fields by writing one of these phrases:
-<programlisting>
+<literallayout class="monospaced">
-    YEAR
+YEAR
-    MONTH
+MONTH
-    DAY
+DAY
-    HOUR
+HOUR
-    MINUTE
+MINUTE
-    SECOND
+SECOND
-    YEAR TO MONTH
+YEAR TO MONTH
-    DAY TO HOUR
+DAY TO HOUR
-    DAY TO MINUTE
+DAY TO MINUTE
-    DAY TO SECOND
+DAY TO SECOND
-    HOUR TO MINUTE
+HOUR TO MINUTE
-    HOUR TO SECOND
+HOUR TO SECOND
-    MINUTE TO SECOND
+MINUTE TO SECOND
-</programlisting>
+</literallayout>
    Note that if both <replaceable>fields</replaceable> and
    <replaceable>p</replaceable> are specified, the
    <replaceable>fields</replaceable> must include <literal>SECOND</>,
@@ -3811,7 +3811,7 @@ SELECT to_tsvector('english', 'The Fat Rats');
     of the operators:
 <programlisting>
- SELECT 'fat &amp; rat'::tsquery;
+SELECT 'fat &amp; rat'::tsquery;
    tsquery    
 ---------------
 'fat' &amp; 'rat'

--- a/doc/src/sgml/dblink.sgml
+++ b/doc/src/sgml/dblink.sgml
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.93 2010/04/06 02:18:04 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.94 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="ddl">
 <title>Data Definition</title>
@@ -2520,7 +2520,7 @@ CREATE TABLE measurement_y2008m01 ( ) INHERITS (measurement);
        just creating the partition tables as above, the table creation
        script should really be:
- <programlisting>
+<programlisting>
 CREATE TABLE measurement_y2006m02 (
    CHECK ( logdate &gt;= DATE '2006-02-01' AND logdate &lt; DATE '2006-03-01' )
 ) INHERITS (measurement);
@@ -2545,7 +2545,7 @@ CREATE TABLE measurement_y2008m01 (
       <para>
        We probably need indexes on the key columns too:
- <programlisting>
+<programlisting>
 CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate);
 CREATE INDEX measurement_y2006m03_logdate ON measurement_y2006m03 (logdate);
 ...

--- a/doc/src/sgml/dict-xsyn.sgml
+++ b/doc/src/sgml/dict-xsyn.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/dict-xsyn.sgml,v 1.3 2009/08/05 18:06:49 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/dict-xsyn.sgml,v 1.4 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="dict-xsyn">
 <title>dict_xsyn</title>
@@ -64,9 +64,9 @@
    <para>
     Each line represents a group of synonyms for a single word, which is
     given first on the line. Synonyms are separated by whitespace, thus:
-    <programlisting>
+<programlisting>
 word syn1 syn2 syn3
-    </programlisting>
+</programlisting>
    </para>
   </listitem>
   <listitem>

--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.100 2010/05/13 14:16:41 mha Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.101 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="ecpg">
 <title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
@@ -2857,11 +2857,11 @@ struct sqlname
   the dollar sign instead of the <literal>EXEC SQL</> primitive to introduce
   embedded SQL commands.:
 <programlisting>
-   $int j = 3;
+$int j = 3;
-   $CONNECT TO :dbname;
+$CONNECT TO :dbname;
-   $CREATE TABLE test(i INT PRIMARY KEY, j INT);
+$CREATE TABLE test(i INT PRIMARY KEY, j INT);
-   $INSERT INTO test(i, j) VALUES (7, :j);
+$INSERT INTO test(i, j) VALUES (7, :j);
-   $COMMIT;
+$COMMIT;
 </programlisting>
  </para>
  <para>
@@ -2898,11 +2898,11 @@ struct sqlname
    supported in Informix-mode without using <literal>typedef</literal>. In fact, in Informix-mode,
    ECPG refuses to process source files that contain <literal>typedef sometype string;</literal>
 <programlisting>
-    EXEC SQL BEGIN DECLARE SECTION;
+EXEC SQL BEGIN DECLARE SECTION;
-    string userid; /* this variable will contain trimmed data */
+string userid; /* this variable will contain trimmed data */
-    EXEC SQL END DECLARE SECTION;
+EXEC SQL END DECLARE SECTION;
-    EXEC SQL FETCH MYCUR INTO :userid;
+EXEC SQL FETCH MYCUR INTO :userid;
 </programlisting>
   </para>
  </sect2>
@@ -2918,8 +2918,8 @@ struct sqlname
        This statement closes the current connection. In fact, this is a
        synonym for ecpg's <literal>DISCONNECT CURRENT</>.:
 <programlisting>
-    $CLOSE DATABASE;                /* close the current connection */
+$CLOSE DATABASE;                /* close the current connection */
-    EXEC SQL CLOSE DATABASE;
+EXEC SQL CLOSE DATABASE;
 </programlisting>
       </para>
      </listitem>
@@ -3083,15 +3083,15 @@ typedef struct sqlda_compat     sqlda_t;
        Pointer to the field data. The pointer is of <literal>char *</literal> type,
        the data pointed by it is in a binary format. Example:
 <programlisting>
-    int intval; 
+int intval; 
-    switch (sqldata->sqlvar[i].sqltype)
+switch (sqldata->sqlvar[i].sqltype)
-    {
+{
    case SQLINTEGER:
        intval = *(int *)sqldata->sqlvar[i].sqldata;
        break;
  ...
-    }
+}
 </programlisting>
       </para>
      </listitem>
@@ -3106,7 +3106,7 @@ typedef struct sqlda_compat     sqlda_t;
        that the value for this field is non-NULL. Otherwise a valid pointer and <literal>sqlitype</literal>
        has to be properly set. Example:
 <programlisting>
-    if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
+if (*(int2 *)sqldata->sqlvar[i].sqlind != 0)
    printf("value is NULL\n");
 </programlisting>
       </para>
@@ -5208,13 +5208,13 @@ EXEC SQL UPDATE Tbl SET col = MYNUMBER;
   <para>
    Example:
 <programlisting>
-   exec sql ifndef TZVAR;
+EXEC SQL ifndef TZVAR;
-   exec sql SET TIMEZONE TO 'GMT';
+EXEC SQL SET TIMEZONE TO 'GMT';
-   exec sql elif TZNAME;
+EXEC SQL elif TZNAME;
-   exec sql SET TIMEZONE TO TZNAME;
+EXEC SQL SET TIMEZONE TO TZNAME;
-   exec sql else;
+EXEC SQL else;
-   exec sql SET TIMEZONE TO TZVAR;
+EXEC SQL SET TIMEZONE TO TZVAR;
-   exec sql endif;
+EXEC SQL endif;
 </programlisting>
   </para>

--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.521 2010/07/03 17:21:48 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.522 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="functions">
  <title>Functions and Operators</title>
@@ -8228,9 +8228,9 @@ SELECT xmlcomment('hello');
     <primary>xmlconcat</primary>
    </indexterm>
- <synopsis>
+<synopsis>
- <function>xmlconcat</function>(<replaceable>xml</replaceable><optional>, ...</optional>)
+<function>xmlconcat</function>(<replaceable>xml</replaceable><optional>, ...</optional>)
- </synopsis>
+</synopsis>
    <para>
     The function <function>xmlconcat</function> concatenates a list
@@ -8286,8 +8286,8 @@ SELECT xmlconcat('<?xml version="1.1"?><foo/>', '<?xml version="1.1" standalone=
   </indexterm>
 <synopsis>
- <function>xmlelement</function>(name <replaceable>name</replaceable> <optional>, xmlattributes(<replaceable>value</replaceable> <optional>AS <replaceable>attname</replaceable></optional> <optional>, ... </optional>)</optional> <optional><replaceable>, content, ...</replaceable></optional>)
+<function>xmlelement</function>(name <replaceable>name</replaceable> <optional>, xmlattributes(<replaceable>value</replaceable> <optional>AS <replaceable>attname</replaceable></optional> <optional>, ... </optional>)</optional> <optional><replaceable>, content, ...</replaceable></optional>)
- </synopsis>
+</synopsis>
    <para>
     The <function>xmlelement</function> expression produces an XML
@@ -8383,9 +8383,9 @@ SELECT xmlelement(name foo, xmlattributes('xyz' as bar),
    <primary>xmlforest</primary>
   </indexterm>
- <synopsis>
+<synopsis>
- <function>xmlforest</function>(<replaceable>content</replaceable> <optional>AS <replaceable>name</replaceable></optional> <optional>, ...</optional>)
+<function>xmlforest</function>(<replaceable>content</replaceable> <optional>AS <replaceable>name</replaceable></optional> <optional>, ...</optional>)
- </synopsis>
+</synopsis>
    <para>
     The <function>xmlforest</function> expression produces an XML
@@ -8440,9 +8440,9 @@ WHERE table_schema = 'pg_catalog';
    <primary>xmlpi</primary>
   </indexterm>
- <synopsis>
+<synopsis>
- <function>xmlpi</function>(name <replaceable>target</replaceable> <optional>, <replaceable>content</replaceable></optional>)
+<function>xmlpi</function>(name <replaceable>target</replaceable> <optional>, <replaceable>content</replaceable></optional>)
- </synopsis>
+</synopsis>
    <para>
     The <function>xmlpi</function> expression creates an XML
@@ -8469,9 +8469,9 @@ SELECT xmlpi(name php, 'echo "hello world";');
    <primary>xmlroot</primary>
   </indexterm>
- <synopsis>
+<synopsis>
- <function>xmlroot</function>(<replaceable>xml</replaceable>, version <replaceable>text</replaceable> | no value <optional>, standalone yes|no|no value</optional>)
+<function>xmlroot</function>(<replaceable>xml</replaceable>, version <replaceable>text</replaceable> | no value <optional>, standalone yes|no|no value</optional>)
- </synopsis>
+</synopsis>
    <para>
     The <function>xmlroot</function> expression alters the properties

--- a/doc/src/sgml/fuzzystrmatch.sgml
+++ b/doc/src/sgml/fuzzystrmatch.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.5 2009/04/06 15:43:00 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/fuzzystrmatch.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="fuzzystrmatch">
 <title>fuzzystrmatch</title>
@@ -34,10 +34,10 @@
   for working with Soundex codes:
  </para>
-  <programlisting>
+<synopsis>
-   soundex(text) returns text
+soundex(text) returns text
-   difference(text, text) returns int
+difference(text, text) returns int
-  </programlisting>
+</synopsis>
  <para>
   The <function>soundex</> function converts a string to its Soundex code.
@@ -53,7 +53,7 @@
   Here are some usage examples:
  </para>
-  <programlisting>
+<programlisting>
 SELECT soundex('hello world!');
 SELECT soundex('Anne'), soundex('Ann'), difference('Anne', 'Ann');
@@ -70,7 +70,7 @@ INSERT INTO s VALUES ('jack');
 SELECT * FROM s WHERE soundex(nm) = soundex('john');
 SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
-  </programlisting>
+</programlisting>
 </sect2>
 <sect2>
@@ -80,10 +80,10 @@ SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
   This function calculates the Levenshtein distance between two strings:
  </para>
-  <programlisting>
+<synopsis>
-   levenshtein(text source, text target, int ins_cost, int del_cost, int sub_cost) returns int
+levenshtein(text source, text target, int ins_cost, int del_cost, int sub_cost) returns int
-   levenshtein(text source, text target) returns int
+levenshtein(text source, text target) returns int
-  </programlisting>
+</synopsis>
  <para>
   Both <literal>source</literal> and <literal>target</literal> can be any
@@ -97,7 +97,7 @@ SELECT * FROM s WHERE difference(s.nm, 'john') &gt; 2;
   Examples:
  </para>
-  <programlisting>
+<screen>
 test=# SELECT levenshtein('GUMBO', 'GAMBOL');
 levenshtein
 -------------
@@ -109,7 +109,7 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
 -------------
           3
 (1 row)
-  </programlisting>
+</screen>
 </sect2>
 <sect2>
@@ -125,9 +125,9 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
   This function calculates the metaphone code of an input string:
  </para>
-  <programlisting>
+<synopsis>
-   metaphone(text source, int max_output_length) returns text
+metaphone(text source, int max_output_length) returns text
-  </programlisting>
+</synopsis>
  <para>
   <literal>source</literal> has to be a non-null string with a maximum of
@@ -140,13 +140,13 @@ test=# SELECT levenshtein('GUMBO', 'GAMBOL', 2,1,1);
   Example:
  </para>
-  <programlisting>
+<screen>
 test=# SELECT metaphone('GUMBO', 4);
 metaphone
 -----------
 KM
 (1 row)
-  </programlisting>
+</screen>
 </sect2>
 <sect2>
@@ -160,10 +160,10 @@ test=# SELECT metaphone('GUMBO', 4);
   These functions compute the primary and alternate codes:
  </para>
-  <programlisting>
+<synopsis>
-   dmetaphone(text source) returns text
+dmetaphone(text source) returns text
-   dmetaphone_alt(text source) returns text
+dmetaphone_alt(text source) returns text
-  </programlisting>
+</synopsis>
  <para>
   There is no length limit on the input strings.
@@ -173,13 +173,13 @@ test=# SELECT metaphone('GUMBO', 4);
   Example:
  </para>
-  <programlisting>
+<screen>
 test=# select dmetaphone('gumbo');
 dmetaphone
 ------------
 KMP
 (1 row)
-  </programlisting>
+</screen>
 </sect2>
 </sect1>
--- a/doc/src/sgml/hstore.sgml
+++ b/doc/src/sgml/hstore.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.12 2010/07/02 20:36:49 rhaas Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/hstore.sgml,v 1.13 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="hstore">
 <title>hstore</title>
@@ -24,11 +24,11 @@
   includes zero or more <replaceable>key</> <literal>=&gt;</>
   <replaceable>value</> pairs separated by commas. Some examples:
-   <programlisting>
+<synopsis>
-    k =&gt; v
+k =&gt; v
-    foo =&gt; bar, baz =&gt; whatever
+foo =&gt; bar, baz =&gt; whatever
-    "1-a" =&gt; "anything at all"
+"1-a" =&gt; "anything at all"
-   </programlisting>
+</synopsis>
   The order of the pairs is not significant (and may not be reproduced on
   output). Whitespace between pairs or around the <literal>=&gt;</> sign is
@@ -42,23 +42,23 @@
   with duplicate keys, only one will be stored in the <type>hstore</> and
   there is no guarantee as to which will be kept:
-   <programlisting>
+<programlisting>
-% select 'a=&gt;1,a=&gt;2'::hstore;
+SELECT 'a=&gt;1,a=&gt;2'::hstore;
  hstore
 ----------
 "a"=&gt;"1"
-   </programlisting>
+</programlisting>
  </para>
  <para>
   A value (but not a key) can be an SQL <literal>NULL</>. For example:
-   <programlisting>
+<programlisting>
-    key =&gt; NULL
+key =&gt; NULL
-   </programlisting>
+</programlisting>
   The <literal>NULL</> keyword is case-insensitive. Double-quote the
-   <literal>NULL</> to treat it as the ordinary string "NULL".
+   <literal>NULL</> to treat it as the ordinary string <quote>NULL</quote>.
  </para>
  <note>
@@ -421,11 +421,11 @@ b
   <type>hstore</> has GiST and GIN index support for the <literal>@&gt;</>,
   <literal>?</>, <literal>?&amp;</> and <literal>?|</> operators. For example:
  </para>
-  <programlisting>
+<programlisting>
 CREATE INDEX hidx ON testhstore USING GIST (h);
 CREATE INDEX hidx ON testhstore USING GIN (h);
-  </programlisting>
+</programlisting>
  <para>
   <type>hstore</> also supports <type>btree</> or <type>hash</> indexes for
@@ -436,11 +436,11 @@ CREATE INDEX hidx ON testhstore USING GIN (h);
   may be useful for equivalence lookups. Create indexes for <literal>=</>
   comparisons as follows:
  </para>
-  <programlisting>
+<programlisting>
 CREATE INDEX hidx ON testhstore USING BTREE (h);
 CREATE INDEX hidx ON testhstore USING HASH (h);
-  </programlisting>
+</programlisting>
 </sect2>
 <sect2>
@@ -448,22 +448,21 @@ CREATE INDEX hidx ON testhstore USING HASH (h);
  <para>
   Add a key, or update an existing key with a new value:
-  </para>
+<programlisting>
-  <programlisting>
 UPDATE tab SET h = h || ('c' =&gt; '3');
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Delete a key:
-  </para>
+<programlisting>
-  <programlisting>
 UPDATE tab SET h = delete(h, 'k1');
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Convert a <type>record</> to an <type>hstore</>:
-  </para>
+<programlisting>
-  <programlisting>
 CREATE TABLE test (col1 integer, col2 text, col3 text);
 INSERT INTO test VALUES (123, 'foo', 'bar');
@@ -472,12 +471,12 @@ SELECT hstore(t) FROM test AS t;
 ---------------------------------------------
 "col1"=&gt;"123", "col2"=&gt;"foo", "col3"=&gt;"bar"
 (1 row)
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Convert an <type>hstore</> to a predefined <type>record</> type:
-  </para>
+<programlisting>
-  <programlisting>
 CREATE TABLE test (col1 integer, col2 text, col3 text);
 SELECT * FROM populate_record(null::test,
@@ -486,12 +485,12 @@ SELECT * FROM populate_record(null::test,
 ------+------+------
  456 | zzz  | 
 (1 row)
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Modify an existing record using the values from an <type>hstore</>:
-  </para>
+<programlisting>
-  <programlisting>
 CREATE TABLE test (col1 integer, col2 text, col3 text);
 INSERT INTO test VALUES (123, 'foo', 'bar');
@@ -500,7 +499,8 @@ SELECT (r).* FROM (SELECT t #= '"col3"=&gt;"baz"' AS r FROM test t) s;
 ------+------+------
  123 | foo  | baz
 (1 row)
-  </programlisting>
+</programlisting>
+  </para>
 </sect2>
 <sect2>
@@ -515,22 +515,21 @@ SELECT (r).* FROM (SELECT t #= '"col3"=&gt;"baz"' AS r FROM test t) s;
  <para>
   Simple example:
-  </para>
+<programlisting>
-  <programlisting>
 SELECT * FROM each('aaa=&gt;bq, b=&gt;NULL, ""=&gt;1');
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Using a table:
-  </para>
+<programlisting>
-  <programlisting>
 SELECT (each(h)).key, (each(h)).value INTO stat FROM testhstore;
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Online statistics:
-  </para>
+<programlisting>
-  <programlisting>
 SELECT key, count(*) FROM
  (SELECT (each(h)).key FROM testhstore) AS stat
  GROUP BY key
@@ -547,7 +546,8 @@ SELECT key, count(*) FROM
 title     |   190
 org       |   189
 ...................
-  </programlisting>
+</programlisting>
+  </para>
 </sect2>
 <sect2>
@@ -572,16 +572,16 @@ SELECT key, count(*) FROM
   performance penalty when processing data that has not yet been modified by
   the new code. It is possible to force an upgrade of all values in a table
   column by doing an <literal>UPDATE</> statement as follows:
-  </para>
+<programlisting>
-  <programlisting>
 UPDATE tablename SET hstorecol = hstorecol || '';
-  </programlisting>
+</programlisting>
+  </para>
  <para>
   Another way to do it is:
-  <programlisting>
+<programlisting>
 ALTER TABLE tablename ALTER hstorecol TYPE hstore USING hstorecol || '';
-  </programlisting>
+</programlisting>
   The <command>ALTER TABLE</> method requires an exclusive lock on the table,
   but does not result in bloating the table with old row versions.
  </para>

--- a/doc/src/sgml/indexam.sgml
+++ b/doc/src/sgml/indexam.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.33 2010/02/08 04:33:51 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/indexam.sgml,v 2.34 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="indexam">
 <title>Index Access Method Interface Definition</title>
@@ -1027,15 +1027,15 @@ amcostestimate (PlannerInfo *root,
     Compute the index access cost.  A generic estimator might do this:
 <programlisting>
-    /*
+/*
 * Our generic assumption is that the index pages will be read
 * sequentially, so they cost seq_page_cost each, not random_page_cost.
 * Also, we charge for evaluation of the indexquals at each index row.
 * All the costs are assumed to be paid incrementally during the scan.
 */
-    cost_qual_eval(&amp;index_qual_cost, indexQuals, root);
+cost_qual_eval(&amp;index_qual_cost, indexQuals, root);
-    *indexStartupCost = index_qual_cost.startup;
+*indexStartupCost = index_qual_cost.startup;
-    *indexTotalCost = seq_page_cost * numIndexPages +
+*indexTotalCost = seq_page_cost * numIndexPages +
    (cpu_index_tuple_cost + index_qual_cost.per_tuple) * numIndexTuples;
 </programlisting>

--- a/doc/src/sgml/install-win32.sgml
+++ b/doc/src/sgml/install-win32.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.58 2010/07/27 19:01:16 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/install-win32.sgml,v 1.59 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="install-win32">
 <title>Installation from Source Code on <productname>Windows</productname></title>
@@ -102,9 +102,9 @@
  and then apply any changes from <filename>config.pl</filename>. For example,
  to specify the location of your <productname>Python</productname> installation,
  put the following in <filename>config.pl</filename>:
-  <screen>
+<programlisting>
-   $config->{python} = 'c:\python26';
+$config->{python} = 'c:\python26';
-  </screen>
+</programlisting>
  You only need to specify those parameters that are different from what's in
  <filename>config_default.pl</filename>.
 </para>
@@ -114,9 +114,9 @@
  <filename>buildenv.pl</filename> and put the required commands there. For
  example, to add the path for bison when it's not in the PATH, create a file
  containing:
-  <screen>
+<programlisting>
-   $ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
+$ENV{PATH}=$ENV{PATH} . ';c:\some\where\bison\bin';
-  </screen>
+</programlisting>
 </para>
 <sect2>
@@ -292,43 +292,31 @@
  <para>
   To build all of PostgreSQL in release configuration (the default), run the
   command:
-   <screen>
+<screen>
-    <userinput>
+<userinput>build</userinput>
-     build
+</screen>
-    </userinput>
-   </screen>
   To build all of PostgreSQL in debug configuration, run the command:
-   <screen>
+<screen>
-    <userinput>
+<userinput>build DEBUG</userinput>
-     build DEBUG
+</screen>
-    </userinput>
-   </screen>
   To build just a single project, for example psql, run the commands:
-   <screen>
+<screen>
-    <userinput>
+<userinput>build psql</userinput>
-     build psql
+<userinput>build DEBUG psql</userinput>
-    </userinput>
+</screen>
-    <userinput>
-     build DEBUG psql
-    </userinput>
-   </screen>
   To change the default build configuration to debug, put the following
   in the <filename>buildenv.pl</filename> file:
-   <screen>
+<programlisting>
-    <userinput>
+$ENV{CONFIG}="Debug";
-     $ENV{CONFIG}="Debug";
+</programlisting>
-    </userinput>
-   </screen>
  </para>
  <para>
   It is also possible to build from inside the Visual Studio GUI. In this
   case, you need to run:
-   <screen>
+<screen>
-    <userinput>
+<userinput>perl mkvcbuild.pl</userinput>
-     perl mkvcbuild.pl
+</screen>
-    </userinput>
-   </screen>
   from the command prompt, and then open the generated
   <filename>pgsql.sln</filename> (in the root directory of the source tree)
   in Visual Studio.
@@ -354,11 +342,9 @@
   <filename>debug</filename> or <filename>release</filename> directories. To
   install these files using the standard layout, and also generate the files
   required to initialize and use the database, run the command:
-   <screen>
+<screen>
-    <userinput>
+<userinput>install c:\destination\directory</userinput>
-     install c:\destination\directory
+</screen>
-    </userinput>
-   </screen>
  </para>
 </sect2>
@@ -373,28 +359,18 @@
   the <filename>buildenv.pl</filename> file. To run the tests, run one of
   the following commands from the <filename>src\tools\msvc</filename>
   directory:
-   <screen>
+<screen>
-    <userinput>
+<userinput>vcregress check</userinput>
-     vcregress check
+<userinput>vcregress installcheck</userinput>
-    </userinput>
+<userinput>vcregress plcheck</userinput>
-    <userinput>
+<userinput>vcregress contribcheck</userinput>
-     vcregress installcheck
+</screen>
-    </userinput>
-    <userinput>
-     vcregress plcheck
-    </userinput>
-    <userinput>
-     vcregress contribcheck
-    </userinput>
-   </screen>
   To change the schedule used (default is parallel), append it to the
   command line like:
-   <screen>
+<screen>
-    <userinput>
+<userinput>vcregress check serial</userinput>
-     vcregress check serial
+</screen>
-    </userinput>
-   </screen>
   For more information about the regression tests, see
   <xref linkend="regress">.
@@ -448,9 +424,9 @@
   </variablelist>
   Edit the <filename>buildenv.pl</filename> file, and add a variable for the
   location of the root directory, for example:
-   <screen>
+<programlisting>
-    $ENV{DOCROOT}='c:\docbook';
+$ENV{DOCROOT}='c:\docbook';
-   </screen>
+</programlisting>
   To build the documentation, run the command
   <filename>builddoc.bat</filename>. Note that this will actually run the
   build twice, in order to generate the indexes. The generated HTML files

--- a/doc/src/sgml/intagg.sgml
+++ b/doc/src/sgml/intagg.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/intagg.sgml,v 1.4 2008/11/14 19:58:45 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/intagg.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="intagg">
 <title>intagg</title>
@@ -44,24 +44,20 @@
  <para>
   Many database systems have the notion of a one to many table. Such a table
   usually sits between two indexed tables, for example:
-  </para>
- <programlisting>
+<programlisting>
 CREATE TABLE left (id INT PRIMARY KEY, ...);
 CREATE TABLE right (id INT PRIMARY KEY, ...);
 CREATE TABLE one_to_many(left INT REFERENCES left, right INT REFERENCES right);
- </programlisting>
+</programlisting>
- <para>
  It is typically used like this:
- </para>
- <programlisting>
+<programlisting>
-  SELECT right.* from right JOIN one_to_many ON (right.id = one_to_many.right)
+SELECT right.* from right JOIN one_to_many ON (right.id = one_to_many.right)
  WHERE one_to_many.left = <replaceable>item</>;
- </programlisting>
+</programlisting>
- <para>
  This will return all the items in the right hand table for an entry
  in the left hand table. This is a very common construct in SQL.
 </para>
@@ -74,35 +70,29 @@ CREATE TABLE one_to_many(left INT REFERENCES left, right INT REFERENCES right);
  left hand entry. If you have a very dynamic system, there is not much you
  can do. However, if you have some data which is fairly static, you can
  create a summary table with the aggregator.
- </para>
- <programlisting>
+<programlisting>
-CREATE TABLE summary as
+CREATE TABLE summary AS
  SELECT left, int_array_aggregate(right) AS right
  FROM one_to_many
  GROUP BY left;
- </programlisting>
+</programlisting>
- <para>
  This will create a table with one row per left item, and an array
  of right items. Now this is pretty useless without some way of using
  the array; that's why there is an array enumerator.  You can do
- </para>
- <programlisting>
+<programlisting>
 SELECT left, int_array_enum(right) FROM summary WHERE left = <replaceable>item</>;
- </programlisting>
+</programlisting>
- <para>
  The above query using <function>int_array_enum</> produces the same results
  as
- </para>
- <programlisting>
+<programlisting>
 SELECT left, right FROM one_to_many WHERE left = <replaceable>item</>;
- </programlisting>
+</programlisting>
- <para>
  The difference is that the query against the summary table has to get
  only one row from the table, whereas the direct query against
  <structname>one_to_many</> must index scan and fetch a row for each entry.
@@ -112,9 +102,8 @@ SELECT left, right FROM one_to_many WHERE left = <replaceable>item</>;
  On one system, an <command>EXPLAIN</> showed a query with a cost of 8488 was
  reduced to a cost of 329.  The original query was a join involving the
  <structname>one_to_many</> table, which was replaced by:
- </para>
- <programlisting>
+<programlisting>
 SELECT right, count(right) FROM
  ( SELECT left, int_array_enum(right) AS right
    FROM summary JOIN (SELECT left FROM left_table WHERE left = <replaceable>item</>) AS lefts
@@ -122,7 +111,8 @@ SELECT right, count(right) FROM
  ) AS list
  GROUP BY right
  ORDER BY count DESC;
- </programlisting>
+</programlisting>
+ </para>
 </sect2>

--- a/doc/src/sgml/intarray.sgml
+++ b/doc/src/sgml/intarray.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.10 2010/05/05 15:10:25 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/intarray.sgml,v 1.11 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="intarray">
 <title>intarray</title>
@@ -271,7 +271,7 @@
 <sect2>
  <title>Example</title>
-  <programlisting>
+<programlisting>
 -- a message can be in one or more <quote>sections</>
 CREATE TABLE message (mid INT PRIMARY KEY, sections INT[], ...);
@@ -286,7 +286,7 @@ SELECT message.mid FROM message WHERE message.sections @&gt; '{1,2}';
 -- the same, using QUERY operator
 SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
-  </programlisting>
+</programlisting>
 </sect2>
 <sect2>
@@ -297,13 +297,13 @@ SELECT message.mid FROM message WHERE message.sections @@ '1&amp;2'::query_int;
   benchmark test suite.  To run:
  </para>
-  <programlisting>
+<programlisting>
-   cd .../bench
+cd .../bench
-   createdb TEST
+createdb TEST
-   psql TEST &lt; ../_int.sql
+psql TEST &lt; ../_int.sql
-   ./create_test.pl | psql TEST
+./create_test.pl | psql TEST
-   ./bench.pl
+./bench.pl
-  </programlisting>
+</programlisting>
  <para>
   The <filename>bench.pl</> script has numerous options, which

--- a/doc/src/sgml/isn.sgml
+++ b/doc/src/sgml/isn.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.5 2009/05/18 11:08:24 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/isn.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="isn">
 <title>isn</title>
@@ -295,7 +295,7 @@
 <sect2>
  <title>Examples</title>
-  <programlisting>
+<programlisting>
 --Using the types directly:
 SELECT isbn('978-0-393-04002-9');
 SELECT isbn13('0901690546');
@@ -333,7 +333,7 @@ UPDATE test SET id = make_valid(id) WHERE id = '2-205-00876-X!';
 SELECT * FROM test;
 SELECT isbn13(id) FROM test;
-  </programlisting>
+</programlisting>
 </sect2>
 <sect2>
@@ -342,24 +342,20 @@ SELECT isbn13(id) FROM test;
  <para>
   The information to implement this module was collected from
   several sites, including:
-  </para>
+   <itemizedlist>
-  <programlisting>
+    <listitem><para><ulink url="http://www.isbn-international.org/"></ulink></para></listitem>
-   http://www.isbn-international.org/
+    <listitem><para><ulink url="http://www.issn.org/"></ulink></para></listitem>
-   http://www.issn.org/
+    <listitem><para><ulink url="http://www.ismn-international.org/"></ulink></para></listitem>
-   http://www.ismn-international.org/
+    <listitem><para><ulink url="http://www.wikipedia.org/"></ulink></para></listitem>
-   http://www.wikipedia.org/
+   </itemizedlist>
-  </programlisting>
-  <para>
   The prefixes used for hyphenation were also compiled from:
-  </para>
+   <itemizedlist>
-  <programlisting>
+    <listitem><para><ulink url="http://www.gs1.org/productssolutions/idkeys/support/prefix_list.html"></ulink></para></listitem>
-   http://www.gs1.org/productssolutions/idkeys/support/prefix_list.html
+    <listitem><para><ulink url="http://www.isbn-international.org/en/identifiers.html"></ulink></para></listitem>
-   http://www.isbn-international.org/en/identifiers.html
+    <listitem><para><ulink url="http://www.ismn-international.org/ranges.html"></ulink></para></listitem>
-   http://www.ismn-international.org/ranges.html
+   </itemizedlist>
-  </programlisting>
-  <para>
   Care was taken during the creation of the algorithms and they
   were meticulously verified against the suggested algorithms
   in the official ISBN, ISMN, ISSN User Manuals.

--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
--- a/doc/src/sgml/lo.sgml
+++ b/doc/src/sgml/lo.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.3 2007/12/06 04:12:10 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/lo.sgml,v 1.4 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="lo">
 <title>lo</title>
@@ -66,12 +66,12 @@
   Here's a simple example of usage:
  </para>
-  <programlisting>
+<programlisting>
-   CREATE TABLE image (title TEXT, raster lo);
+CREATE TABLE image (title TEXT, raster lo);
-   CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
+CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
    FOR EACH ROW EXECUTE PROCEDURE lo_manage(raster);
-  </programlisting>
+</programlisting>
  <para>
   For each column that will contain unique references to large objects,

--- a/doc/src/sgml/ltree.sgml
+++ b/doc/src/sgml/ltree.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.4 2010/03/17 17:12:31 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ltree.sgml,v 1.5 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="ltree">
 <title>ltree</title>
@@ -58,32 +58,32 @@
     for matching <type>ltree</> values.  A simple word matches that
     label within a path.  A star symbol (<literal>*</>) matches zero
     or more labels.  For example:
-     <programlisting>
+<synopsis>
 foo         <lineannotation>Match the exact label path <literal>foo</></lineannotation>
 *.foo.*     <lineannotation>Match any label path containing the label <literal>foo</></lineannotation>
 *.foo       <lineannotation>Match any label path whose last label is <literal>foo</></lineannotation>
-     </programlisting>
+</synopsis>
    </para>
    <para>
     Star symbols can also be quantified to restrict how many labels
     they can match:
-     <programlisting>
+<synopsis>
 *{<replaceable>n</>}        <lineannotation>Match exactly <replaceable>n</> labels</lineannotation>
 *{<replaceable>n</>,}       <lineannotation>Match at least <replaceable>n</> labels</lineannotation>
 *{<replaceable>n</>,<replaceable>m</>}      <lineannotation>Match at least <replaceable>n</> but not more than <replaceable>m</> labels</lineannotation>
 *{,<replaceable>m</>}       <lineannotation>Match at most <replaceable>m</> labels &mdash; same as </lineannotation> *{0,<replaceable>m</>}
-     </programlisting>
+</synopsis>
    </para>
    <para>
     There are several modifiers that can be put at the end of a non-star
     label in <type>lquery</> to make it match more than just the exact match:
-     <programlisting>
+<synopsis>
 @           <lineannotation>Match case-insensitively, for example <literal>a@</> matches <literal>A</></lineannotation>
 *           <lineannotation>Match any label with this prefix, for example <literal>foo*</> matches <literal>foobar</></lineannotation>
 %           <lineannotation>Match initial underscore-separated words</lineannotation>
-     </programlisting>
+</synopsis>
     The behavior of <literal>%</> is a bit complicated.  It tries to match
     words rather than the entire label.  For example
     <literal>foo_bar%</> matches <literal>foo_bar_baz</> but not
@@ -102,10 +102,10 @@ foo         <lineannotation>Match the exact label path <literal>foo</></lineanno
    <para>
     Here's an annotated example of <type>lquery</type>:
-    <programlisting>
+<programlisting>
-     Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
+Top.*{0,2}.sport*@.!football|tennis.Russ*|Spain
-     a.  b.     c.      d.               e.
+a.  b.     c.      d.               e.
-    </programlisting>
+</programlisting>
     This query will match any label path that:
    </para>
    <orderedlist numeration='loweralpha'>
@@ -154,9 +154,9 @@ foo         <lineannotation>Match the exact label path <literal>foo</></lineanno
    <para>
     Here's an example <type>ltxtquery</type>:
-    <programlisting>
+<programlisting>
-     Europe &amp; Russia*@ &amp; !Transportation
+Europe &amp; Russia*@ &amp; !Transportation
-    </programlisting>
+</programlisting>
     This will match paths that contain the label <literal>Europe</literal> and
     any label beginning with <literal>Russia</literal> (case-insensitive),
     but not paths containing the label <literal>Transportation</literal>.
@@ -504,9 +504,9 @@ foo         <lineannotation>Match the exact label path <literal>foo</></lineanno
    <para>
     Example of creating such an index:
    </para>
-    <programlisting>
+<programlisting>
-     CREATE INDEX path_gist_idx ON test USING GIST (path);
+CREATE INDEX path_gist_idx ON test USING GIST (path);
-    </programlisting>
+</programlisting>
   </listitem>
   <listitem>
    <para>
@@ -517,9 +517,9 @@ foo         <lineannotation>Match the exact label path <literal>foo</></lineanno
    <para>
     Example of creating such an index:
    </para>
-    <programlisting>
+<programlisting>
-     CREATE INDEX path_gist_idx ON test USING GIST (array_path);
+CREATE INDEX path_gist_idx ON test USING GIST (array_path);
-    </programlisting>
+</programlisting>
    <para>
     Note: This index type is lossy.
    </para>
@@ -535,7 +535,7 @@ foo         <lineannotation>Match the exact label path <literal>foo</></lineanno
   <filename>contrib/ltree/ltreetest.sql</> in the source distribution):
  </para>
-  <programlisting>
+<programlisting>
 CREATE TABLE test (path ltree);
 INSERT INTO test VALUES ('Top');
 INSERT INTO test VALUES ('Top.Science');
@@ -552,31 +552,29 @@ INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Galaxies');
 INSERT INTO test VALUES ('Top.Collections.Pictures.Astronomy.Astronauts');
 CREATE INDEX path_gist_idx ON test USING gist(path);
 CREATE INDEX path_idx ON test USING btree(path);
-  </programlisting>
+</programlisting>
  <para>
   Now, we have a table <structname>test</> populated with data describing
   the hierarchy shown below:
  </para>
-  <programlisting>
+<literallayout class="monospaced">
                        Top
                     /   |  \
             Science Hobbies Collections
                 /       |              \
        Astronomy   Amateurs_Astronomy Pictures
           /  \                            |
-    Astrophysics  Cosmology                Astronomy
+Astrophysics  Cosmology                Astronomy
                                        /  |    \
                                 Galaxies Stars Astronauts
-  </programlisting>
+</literallayout>
  <para>
   We can do inheritance:
-  </para>
+<screen>
+ltreetest=&gt; SELECT path FROM test WHERE path &lt;@ 'Top.Science';
-  <programlisting>
-ltreetest=# select path from test where path &lt;@ 'Top.Science';
                path
 ------------------------------------
 Top.Science
@@ -584,14 +582,13 @@ ltreetest=# select path from test where path &lt;@ 'Top.Science';
 Top.Science.Astronomy.Astrophysics
 Top.Science.Astronomy.Cosmology
 (4 rows)
-  </programlisting>
+</screen>
+  </para>
  <para>
   Here are some examples of path matching:
-  </para>
+<screen>
+ltreetest=&gt; SELECT path FROM test WHERE path ~ '*.Astronomy.*';
-  <programlisting>
-ltreetest=# select path from test where path ~ '*.Astronomy.*';
                     path
 -----------------------------------------------
 Top.Science.Astronomy
@@ -603,20 +600,20 @@ ltreetest=# select path from test where path ~ '*.Astronomy.*';
 Top.Collections.Pictures.Astronomy.Astronauts
 (7 rows)
-ltreetest=# select path from test where path ~ '*.!pictures@.*.Astronomy.*';
+ltreetest=&gt; SELECT path FROM test WHERE path ~ '*.!pictures@.*.Astronomy.*';
                path
 ------------------------------------
 Top.Science.Astronomy
 Top.Science.Astronomy.Astrophysics
 Top.Science.Astronomy.Cosmology
 (3 rows)
-  </programlisting>
+</screen>
+  </para>
  <para>
   Here are some examples of full text search:
-  </para>
+<screen>
-  <programlisting>
+ltreetest=&gt; SELECT path FROM test WHERE path @ 'Astro*% &amp; !pictures@';
-ltreetest=# select path from test where path @ 'Astro*% &amp; !pictures@';
                path
 ------------------------------------
 Top.Science.Astronomy
@@ -625,45 +622,46 @@ ltreetest=# select path from test where path @ 'Astro*% &amp; !pictures@';
 Top.Hobbies.Amateurs_Astronomy
 (4 rows)
-ltreetest=# select path from test where path @ 'Astro* &amp; !pictures@';
+ltreetest=&gt; SELECT path FROM test WHERE path @ 'Astro* &amp; !pictures@';
                path
 ------------------------------------
 Top.Science.Astronomy
 Top.Science.Astronomy.Astrophysics
 Top.Science.Astronomy.Cosmology
 (3 rows)
-  </programlisting>
+</screen>
+  </para>
  <para>
   Path construction using functions:
-  </para>
+<screen>
-  <programlisting>
+ltreetest=&gt; SELECT subpath(path,0,2)||'Space'||subpath(path,2) FROM test WHERE path &lt;@ 'Top.Science.Astronomy';
-ltreetest=# select subpath(path,0,2)||'Space'||subpath(path,2) from test where path &lt;@ 'Top.Science.Astronomy';
                 ?column?
 ------------------------------------------
 Top.Science.Space.Astronomy
 Top.Science.Space.Astronomy.Astrophysics
 Top.Science.Space.Astronomy.Cosmology
 (3 rows)
-  </programlisting>
+</screen>
+  </para>
  <para>
   We could simplify this by creating a SQL function that inserts a label
   at a specified position in a path:
-  </para>
+<screen>
-  <programlisting>
 CREATE FUNCTION ins_label(ltree, int, text) RETURNS ltree
-AS 'select subpath($1,0,$2) || $3 || subpath($1,$2);'
+    AS 'select subpath($1,0,$2) || $3 || subpath($1,$2);'
-LANGUAGE SQL IMMUTABLE;
+    LANGUAGE SQL IMMUTABLE;
-ltreetest=# select ins_label(path,2,'Space') from test where path &lt;@ 'Top.Science.Astronomy';
+ltreetest=&gt; SELECT ins_label(path,2,'Space') FROM test WHERE path &lt;@ 'Top.Science.Astronomy';
                ins_label
 ------------------------------------------
 Top.Science.Space.Astronomy
 Top.Science.Space.Astronomy.Astrophysics
 Top.Science.Space.Astronomy.Cosmology
 (3 rows)
-  </programlisting>
+</screen>
+  </para>
 </sect2>
 <sect2>

--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.80 2010/04/26 19:56:55 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/monitoring.sgml,v 1.81 2010/07/29 19:34:40 petere Exp $ -->
 <chapter id="monitoring">
 <title>Monitoring Database Activity</title>
@@ -1680,7 +1680,7 @@ Total time (ns)                        2312105013
    <para>
     Add the probe definition to <filename>src/backend/utils/probes.d</>:
 <programlisting>
-      probe transaction__start(LocalTransactionId);
+probe transaction__start(LocalTransactionId);
 </programlisting>
     Note the use of the double underline in the probe name. In a DTrace
     script using the probe, the double underline needs to be replaced with a
@@ -1698,7 +1698,7 @@ Total time (ns)                        2312105013
     in the source code.  In this case, it looks like the following:
 <programlisting>
-    TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
+TRACE_POSTGRESQL_TRANSACTION_START(vxid.localTransactionId);
 </programlisting>
    </para>
   </step>
@@ -1748,7 +1748,7 @@ Total time (ns)                        2312105013
      is actually enabled:
 <programlisting>
-    if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
+if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
    TRACE_POSTGRESQL_TRANSACTION_START(some_function(...));
 </programlisting>

--- a/doc/src/sgml/oid2name.sgml
+++ b/doc/src/sgml/oid2name.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.8 2010/05/25 15:55:28 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/oid2name.sgml,v 1.9 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="oid2name">
 <title>oid2name</title>
@@ -147,7 +147,7 @@
 <sect2>
  <title>Examples</title>
-  <programlisting>
+<screen>
 $ # what's in this database server, anyway?
 $ oid2name
 All databases:
@@ -264,7 +264,7 @@ From database "alvherre":
  Filenode  Table Name
 ----------------------
    155156         foo
-  </programlisting>
+</screen>
 </sect2>
 <sect2>

--- a/doc/src/sgml/pageinspect.sgml
+++ b/doc/src/sgml/pageinspect.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.6 2009/06/08 16:22:44 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pageinspect.sgml,v 1.7 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pageinspect">
 <title>pageinspect</title>
@@ -62,15 +62,12 @@
     <para>
      A page image obtained with <function>get_raw_page</function> should be
      passed as argument.  For example:
-     </para>
+<screen>
-     <programlisting>
 test=# SELECT * FROM page_header(get_raw_page('pg_class', 0));
    lsn    | tli | flags | lower | upper | special | pagesize | version | prune_xid
 -----------+-----+-------+-------+-------+---------+----------+---------+-----------
 0/24A1B50 |   1 |     1 |   232 |   368 |    8192 |     8192 |       4 |         0
-     </programlisting>
+</screen>
-     <para>
      The returned columns correspond to the fields in the
      <structname>PageHeaderData</> struct.
      See <filename>src/include/storage/bufpage.h</> for details.
@@ -93,11 +90,9 @@ test=# SELECT * FROM page_header(get_raw_page('pg_class', 0));
     <para>
      A heap page image obtained with <function>get_raw_page</function> should
      be passed as argument.  For example:
-     </para>
+<screen>
-     <programlisting>
 test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
-     </programlisting>
+</screen>
-     <para>
      See <filename>src/include/storage/itemid.h</> and
      <filename>src/include/access/htup.h</> for explanations of the fields
      returned.
@@ -114,8 +109,7 @@ test=# SELECT * FROM heap_page_items(get_raw_page('pg_class', 0));
     <para>
      <function>bt_metap</function> returns information about a btree
      index's metapage.  For example:
-     </para>
+<screen>
-     <programlisting>
 test=# SELECT * FROM bt_metap('pg_cast_oid_index');
 -[ RECORD 1 ]-----
 magic     | 340322
@@ -124,7 +118,8 @@ root      | 1
 level     | 0
 fastroot  | 1
 fastlevel | 0
-     </programlisting>
+</screen>
+     </para>
    </listitem>
   </varlistentry>
@@ -137,8 +132,7 @@ fastlevel | 0
     <para>
      <function>bt_page_stats</function> returns summary information about
      single pages of btree indexes.  For example:
-     </para>
+<screen>
-     <programlisting>
 test=# SELECT * FROM bt_page_stats('pg_cast_oid_index', 1);
 -[ RECORD 1 ]-+-----
 blkno         | 1
@@ -152,7 +146,8 @@ btpo_prev     | 0
 btpo_next     | 0
 btpo          | 0
 btpo_flags    | 3
-     </programlisting>
+</screen>
+     </para>
    </listitem>
   </varlistentry>
@@ -165,8 +160,7 @@ btpo_flags    | 3
     <para>
      <function>bt_page_items</function> returns detailed information about
      all of the items on a btree index page.  For example:
-     </para>
+<screen>
-     <programlisting>
 test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
 itemoffset |  ctid   | itemlen | nulls | vars |    data
 ------------+---------+---------+-------+------+-------------
@@ -178,7 +172,8 @@ test=# SELECT * FROM bt_page_items('pg_cast_oid_index', 1);
          6 | (0,6)   |      12 | f     | f    | 28 27 00 00
          7 | (0,7)   |      12 | f     | f    | 29 27 00 00
          8 | (0,8)   |      12 | f     | f    | 2a 27 00 00
-     </programlisting>
+</screen>
+     </para>
    </listitem>
   </varlistentry>

--- a/doc/src/sgml/pgarchivecleanup.sgml
+++ b/doc/src/sgml/pgarchivecleanup.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.1 2010/06/14 17:25:24 sriggs Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pgarchivecleanup.sgml,v 1.2 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pgarchivecleanup">
 <title>pg_archivecleanup</title>
@@ -38,11 +38,9 @@
   To configure a standby
   server to use <application>pg_archivecleanup</>, put this into its
   <filename>recovery.conf</filename> configuration file:
-  </para>
+<programlisting>
-  <programlisting>
 archive_cleanup_command = 'pg_archivecleanup <replaceable>archiveDir</> %r'
-  </programlisting>
+</programlisting>
-  <para>
   where <replaceable>archiveDir</> is the directory from which WAL segment
   files should be restored.
  </para>
@@ -58,11 +56,9 @@ archive_cleanup_command = 'pg_archivecleanup <replaceable>archiveDir</> %r'
  </para>
  <para>
   The full syntax of <application>pg_archivecleanup</>'s command line is
-  </para>
+<synopsis>
-  <synopsis>
 pg_archivecleanup <optional> <replaceable>option</> ... </optional> <replaceable>archivelocation</> <replaceable>restartwalfile</>
-  </synopsis>
+</synopsis>
-  <para>
   When used as a standalone program all WAL files logically preceding the 
   <literal>restartwalfile</> will be removed <replaceable>archivelocation</>.
   In this mode, if you specify a .backup filename, then only the file prefix
@@ -70,15 +66,13 @@ pg_archivecleanup <optional> <replaceable>option</> ... </optional> <replaceable
   all WAL files archived prior to a specific base backup without error.
   For example, the following example will remove all files older than
   WAL filename 000000010000003700000010:
-  </para>
+<programlisting>
-  <programlisting>
 pg_archivecleanup -d archive 000000010000003700000010.00000020.backup
 pg_archivecleanup:  keep WAL files 000000010000003700000010 and later
 pg_archivecleanup:  removing "archive/00000001000000370000000F"
 pg_archivecleanup:  removing "archive/00000001000000370000000E"
-  </programlisting>
+</programlisting>
-  <para>
   <application>pg_archivecleanup</application> assumes that
   <replaceable>archivelocation</> is a directory readable and writable by the
   server-owning user.
@@ -110,12 +104,10 @@ pg_archivecleanup:  removing "archive/00000001000000370000000E"
 <sect2>
  <title>Examples</title>
-  <para>On Linux or Unix systems, you might use:</para>
+  <para>On Linux or Unix systems, you might use:
+<programlisting>
-  <programlisting>
 archive_cleanup_command = 'pg_archivecleanup -d .../archive %r 2>>cleanup.log'
-  </programlisting>
+</programlisting>
-  <para>
   where the archive directory is physically located on the standby server,
   so that the <literal>archive_command</> is accessing it across NFS,
   but the files are local to the standby.

--- a/doc/src/sgml/pgbench.sgml
+++ b/doc/src/sgml/pgbench.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.16 2010/05/25 15:55:28 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbench.sgml,v 1.17 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pgbench">
 <title>pgbench</title>
@@ -22,7 +22,7 @@
 <para>
  Typical output from pgbench looks like:
- <programlisting>
+<screen>
 transaction type: TPC-B (sort of)
 scaling factor: 10
 query mode: simple
@@ -32,7 +32,7 @@ number of transactions per client: 1000
 number of transactions actually processed: 10000/10000
 tps = 85.184871 (including connections establishing)
 tps = 85.296346 (excluding connections establishing)
- </programlisting>
+</screen>
  The first six lines report some of the most important parameter
  settings.  The next line reports the number of transactions completed
@@ -53,9 +53,9 @@ tps = 85.296346 (excluding connections establishing)
   step, but will instead need to do whatever setup your test needs.)
   Initialization looks like:
-   <programlisting>
+<programlisting>
 pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbname</>
-   </programlisting>
+</programlisting>
   where <replaceable>dbname</> is the name of the already-created
   database to test in.  (You may also need <literal>-h</>,
@@ -77,16 +77,14 @@ pgbench -i <optional> <replaceable>other-options</> </optional> <replaceable>dbn
  <para>
   At the default <quote>scale factor</> of 1, the tables initially
   contain this many rows:
-  </para>
+<screen>
-  <programlisting>
 table                   # of rows
 ---------------------------------
 pgbench_branches        1
 pgbench_tellers         10
 pgbench_accounts        100000
 pgbench_history         0
-  </programlisting>
+</screen>
-  <para>
   You can (and, for most purposes, probably should) increase the number
   of rows by using the <literal>-s</> (scale factor) option.  The
   <literal>-F</> (fillfactor) option might also be used at this point.
@@ -96,9 +94,9 @@ pgbench_history         0
   Once you have done the necessary setup, you can run your benchmark
   with a command that doesn't include <literal>-i</>, that is
-   <programlisting>
+<programlisting>
 pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
-   </programlisting>
+</programlisting>
   In nearly all cases, you'll need some options to make a useful test.
   The most important options are <literal>-c</> (number of clients),
@@ -478,9 +476,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
     <para>
      Example:
-      <programlisting>
+<programlisting>
 \set ntellers 10 * :scale
-      </programlisting>
+</programlisting>
     </para>
    </listitem>
   </varlistentry>
@@ -501,9 +499,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
     <para>
      Example:
-      <programlisting>
+<programlisting>
 \setrandom aid 1 :naccounts
-      </programlisting>
+</programlisting>
     </para>
    </listitem>
   </varlistentry>
@@ -525,9 +523,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
     <para>
      Example:
-      <programlisting>
+<programlisting>
 \sleep 10 ms
-      </programlisting>
+</programlisting>
     </para>
    </listitem>
   </varlistentry>
@@ -554,9 +552,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
     <para>
      Example:
-      <programlisting>
+<programlisting>
 \setshell variable_to_be_assigned command literal_argument :variable ::literal_starting_with_colon
-      </programlisting>
+</programlisting>
     </para>
    </listitem>
   </varlistentry>
@@ -573,9 +571,9 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
     <para>
      Example:
-      <programlisting>
+<programlisting>
 \shell command literal_argument :variable ::literal_starting_with_colon
-      </programlisting>
+</programlisting>
     </para>
    </listitem>
   </varlistentry>
@@ -585,7 +583,7 @@ pgbench <optional> <replaceable>options</> </optional> <replaceable>dbname</>
   As an example, the full definition of the built-in TPC-B-like
   transaction is:
-   <programlisting>
+<programlisting>
 \set nbranches :scale
 \set ntellers 10 * :scale
 \set naccounts 100000 * :scale
@@ -600,7 +598,7 @@ UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
 INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
 END;
-   </programlisting>
+</programlisting>
   This script allows each iteration of the transaction to reference
   different, randomly-chosen rows.  (This example also shows why it's
@@ -630,9 +628,9 @@ END;
  <para>
   The format of the log is:
-   <programlisting>
+<synopsis>
-    <replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</>
+<replaceable>client_id</> <replaceable>transaction_no</> <replaceable>time</> <replaceable>file_no</> <replaceable>time_epoch</> <replaceable>time_us</>
-   </programlisting>
+</synopsis>
   where <replaceable>time</> is the elapsed transaction time in microseconds,
   <replaceable>file_no</> identifies which script file was used
@@ -646,12 +644,12 @@ END;
  <para>
   Here are example outputs:
-   <programlisting>
+<screen>
 0 199 2241 0 1175850568 995598
 0 200 2465 0 1175850568 998079
 0 201 2513 0 1175850569 608
 0 202 2038 0 1175850569 2663
-   </programlisting>
+</screen>
  </para>
 </sect2>

--- a/doc/src/sgml/pgbuffercache.sgml
+++ b/doc/src/sgml/pgbuffercache.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbuffercache.sgml,v 2.6 2010/02/07 20:48:09 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pgbuffercache.sgml,v 2.7 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pgbuffercache">
 <title>pg_buffercache</title>
@@ -134,8 +134,8 @@
 <sect2>
  <title>Sample output</title>
-  <programlisting>
+<screen>
-  regression=# SELECT c.relname, count(*) AS buffers
+regression=# SELECT c.relname, count(*) AS buffers
             FROM pg_buffercache b INNER JOIN pg_class c
             ON b.relfilenode = pg_relation_filenode(c.oid) AND
                b.reldatabase IN (0, (SELECT oid FROM pg_database
@@ -143,8 +143,9 @@
             GROUP BY c.relname
             ORDER BY 2 DESC
             LIMIT 10;
             relname             | buffers
-  ---------------------------------+---------
+---------------------------------+---------
 tenk2                           |     345
 tenk1                           |     141
 pg_proc                         |      46
@@ -155,8 +156,8 @@
 pg_attribute_relid_attnam_index |      26
 pg_depend                       |      22
 pg_depend_reference_index       |      20
-  (10 rows)
+(10 rows)
-  </programlisting>
+</screen>
 </sect2>
 <sect2>

--- a/doc/src/sgml/pgcrypto.sgml
+++ b/doc/src/sgml/pgcrypto.sgml
--- a/doc/src/sgml/pgfreespacemap.sgml
+++ b/doc/src/sgml/pgfreespacemap.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.6 2010/04/23 23:21:43 rhaas Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pgfreespacemap.sgml,v 2.7 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pgfreespacemap">
 <title>pg_freespacemap</title>
@@ -75,7 +75,7 @@
 <sect2>
  <title>Sample output</title>
-  <programlisting>
+<screen>
 postgres=# SELECT * FROM pg_freespace('foo');
 blkno | avail 
 -------+-------
@@ -106,8 +106,7 @@ postgres=# SELECT * FROM pg_freespace('foo', 7);
 --------------
         1216
 (1 row)
+</screen>
-  </programlisting>
 </sect2>
 <sect2>

--- a/doc/src/sgml/pgrowlocks.sgml
+++ b/doc/src/sgml/pgrowlocks.sgml
-<!-- $PostgreSQL: pgsql/doc/src/sgml/pgrowlocks.sgml,v 1.5 2009/05/18 11:08:24 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/pgrowlocks.sgml,v 1.6 2010/07/29 19:34:40 petere Exp $ -->
 <sect1 id="pgrowlocks">
 <title>pgrowlocks</title>
@@ -101,10 +101,10 @@ pgrowlocks(text) returns setof record
   rows. If you want to take a look at the row contents at the same time, you
   could do something like this:
-  <programlisting>
+<programlisting>
 SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
  WHERE p.locked_row = a.ctid;
-  </programlisting>
+</programlisting>
   Be aware however that (as of <productname>PostgreSQL</> 8.3) such a
   query will be very inefficient.
@@ -114,7 +114,7 @@ SELECT * FROM accounts AS a, pgrowlocks('accounts') AS p
 <sect2>
  <title>Sample output</title>
-  <programlisting>
+<screen>
 test=# SELECT * FROM pgrowlocks('t1');
 locked_row | lock_type | locker | multi |   xids    |     pids
 ------------+-----------+--------+-------+-----------+---------------
@@ -123,7 +123,7 @@ test=# SELECT * FROM pgrowlocks('t1');
      (0,3) | Exclusive |    804 | f     | {804}     | {29066}
      (0,4) | Exclusive |    804 | f     | {804}     | {29066}
 (4 rows)
-  </programlisting>
+</screen>
 </sect2>
 <sect2>

--- a/doc/src/sgml/pgstandby.sgml
+++ b/doc/src/sgml/pgstandby.sgml
--- a/doc/src/sgml/pgstatstatements.sgml
+++ b/doc/src/sgml/pgstatstatements.sgml
--- a/doc/src/sgml/pgstattuple.sgml
+++ b/doc/src/sgml/pgstattuple.sgml
--- a/doc/src/sgml/pgtrgm.sgml
+++ b/doc/src/sgml/pgtrgm.sgml
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
--- a/doc/src/sgml/ref/alter_domain.sgml
+++ b/doc/src/sgml/ref/alter_domain.sgml
--- a/doc/src/sgml/ref/alter_sequence.sgml
+++ b/doc/src/sgml/ref/alter_sequence.sgml
--- a/doc/src/sgml/ref/alter_type.sgml
+++ b/doc/src/sgml/ref/alter_type.sgml
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
--- a/doc/src/sgml/release-8.1.sgml
+++ b/doc/src/sgml/release-8.1.sgml
--- a/doc/src/sgml/release-old.sgml
+++ b/doc/src/sgml/release-old.sgml
--- a/doc/src/sgml/seg.sgml
+++ b/doc/src/sgml/seg.sgml
--- a/doc/src/sgml/sql.sgml
+++ b/doc/src/sgml/sql.sgml
--- a/doc/src/sgml/sslinfo.sgml
+++ b/doc/src/sgml/sslinfo.sgml
--- a/doc/src/sgml/stylesheet.css
+++ b/doc/src/sgml/stylesheet.css
--- a/doc/src/sgml/tablefunc.sgml
+++ b/doc/src/sgml/tablefunc.sgml
--- a/doc/src/sgml/textsearch.sgml
+++ b/doc/src/sgml/textsearch.sgml
--- a/doc/src/sgml/unaccent.sgml
+++ b/doc/src/sgml/unaccent.sgml
--- a/doc/src/sgml/uuid-ossp.sgml
+++ b/doc/src/sgml/uuid-ossp.sgml
--- a/doc/src/sgml/vacuumlo.sgml
+++ b/doc/src/sgml/vacuumlo.sgml
--- a/doc/src/sgml/xaggr.sgml
+++ b/doc/src/sgml/xaggr.sgml
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
--- a/doc/src/sgml/xml2.sgml
+++ b/doc/src/sgml/xml2.sgml