Convert documentation to DocBook XML

Since some preparation work had already been done, the only source
changes left were changing empty-element tags like <xref linkend="foo">
to <xref linkend="foo"/>, and changing the DOCTYPE.

The source files are still named *.sgml, but they are actually XML files
now.  Renaming could be considered later.

In the build system, the intermediate step to convert from SGML to XML
is removed.  Everything is build straight from the source files again.
The OpenSP (or the old SP) package is no longer needed.

The documentation toolchain instructions are updated and are much
simpler now.

Peter Eisentraut, Alexander Lakhin, Jürgen Purtz

1 files changed, 20 insertions, 20 deletions

diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 265effbe48b..54b5e98a0e3 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -15,7 +15,7 @@
 
  <para>
   The functionality provided by this module overlaps substantially
-  with the functionality of the older <xref linkend="dblink"> module.
+  with the functionality of the older <xref linkend="dblink"/> module.
   But <filename>postgres_fdw</filename> provides more transparent and
   standards-compliant syntax for accessing remote tables, and can give
   better performance in many cases.
@@ -27,12 +27,12 @@
    <listitem>
     <para>
      Install the  <filename>postgres_fdw</filename> extension using <xref
-     linkend="sql-createextension">.
+     linkend="sql-createextension"/>.
     </para>
    </listitem>
    <listitem>
     <para>
-     Create a foreign server object, using <xref linkend="sql-createserver">,
+     Create a foreign server object, using <xref linkend="sql-createserver"/>,
      to represent each remote database you want to connect to.
      Specify connection information, except <literal>user</literal> and
      <literal>password</literal>, as options of the server object.
@@ -40,7 +40,7 @@
    </listitem>
    <listitem>
     <para>
-     Create a user mapping, using <xref linkend="sql-createusermapping">, for
+     Create a user mapping, using <xref linkend="sql-createusermapping"/>, for
      each database user you want to allow to access each foreign server.
      Specify the remote user name and password to use as
      <literal>user</literal> and <literal>password</literal> options of the
@@ -49,8 +49,8 @@
    </listitem>
    <listitem>
     <para>
-     Create a foreign table, using <xref linkend="sql-createforeigntable">
-     or <xref linkend="sql-importforeignschema">,
+     Create a foreign table, using <xref linkend="sql-createforeigntable"/>
+     or <xref linkend="sql-importforeignschema"/>,
      for each remote table you want to access.  The columns of the foreign
      table must match the referenced remote table.  You can, however, use
      table and/or column names different from the remote table's, if you
@@ -101,7 +101,7 @@
    <para>
     A foreign server using the <filename>postgres_fdw</filename> foreign data wrapper
     can have the same options that <application>libpq</application> accepts in
-    connection strings, as described in <xref linkend="libpq-paramkeywords">,
+    connection strings, as described in <xref linkend="libpq-paramkeywords"/>,
     except that these options are not allowed:
 
     <itemizedlist spacing="compact">
@@ -254,7 +254,7 @@
     <literal>fdw_tuple_cost</literal> to the cost estimates.  This local
     estimation is unlikely to be very accurate unless local copies of the
     remote table's statistics are available.  Running
-    <xref linkend="sql-analyze"> on the foreign table is the way to update
+    <xref linkend="sql-analyze"/> on the foreign table is the way to update
     the local statistics; this will perform a scan of the remote table and
     then calculate and store statistics just as though the table were local.
     Keeping local statistics can be a useful way to reduce per-query planning
@@ -359,7 +359,7 @@
 
    <para>
     <filename>postgres_fdw</filename> is able to import foreign table definitions
-    using <xref linkend="sql-importforeignschema">.  This command creates
+    using <xref linkend="sql-importforeignschema"/>.  This command creates
     foreign table definitions on the local server that match tables or
     views present on the remote server.  If the remote tables to be imported
     have columns of user-defined data types, the local server must have
@@ -423,7 +423,7 @@
     So if you wish to import <literal>CHECK</literal> constraints, you must do so
     manually, and you should verify the semantics of each one carefully.
     For more detail about the treatment of <literal>CHECK</literal> constraints on
-    foreign tables, see <xref linkend="sql-createforeigntable">.
+    foreign tables, see <xref linkend="sql-createforeigntable"/>.
    </para>
 
    <para>
@@ -528,7 +528,7 @@
 
   <para>
    In the remote sessions opened by <filename>postgres_fdw</filename>,
-   the <xref linkend="guc-search-path"> parameter is set to
+   the <xref linkend="guc-search-path"/> parameter is set to
    just <literal>pg_catalog</literal>, so that only built-in objects are visible
    without schema qualification.  This is not an issue for queries
    generated by <filename>postgres_fdw</filename> itself, because it always
@@ -538,7 +538,7 @@
    any functions used in that view will be executed with the restricted
    search path.  It is recommended to schema-qualify all names in such
    functions, or else attach <literal>SET search_path</literal> options
-   (see <xref linkend="sql-createfunction">) to such functions
+   (see <xref linkend="sql-createfunction"/>) to such functions
    to establish their expected search path environment.
   </para>
 
@@ -548,22 +548,22 @@
    <itemizedlist spacing="compact">
     <listitem>
      <para>
-      <xref linkend="guc-timezone"> is set to <literal>UTC</literal>
+      <xref linkend="guc-timezone"/> is set to <literal>UTC</literal>
      </para>
     </listitem>
     <listitem>
      <para>
-      <xref linkend="guc-datestyle"> is set to <literal>ISO</literal>
+      <xref linkend="guc-datestyle"/> is set to <literal>ISO</literal>
      </para>
     </listitem>
     <listitem>
      <para>
-      <xref linkend="guc-intervalstyle"> is set to <literal>postgres</literal>
+      <xref linkend="guc-intervalstyle"/> is set to <literal>postgres</literal>
      </para>
     </listitem>
     <listitem>
      <para>
-      <xref linkend="guc-extra-float-digits"> is set to <literal>3</literal> for remote
+      <xref linkend="guc-extra-float-digits"/> is set to <literal>3</literal> for remote
       servers 9.0 and newer and is set to <literal>2</literal> for older versions
      </para>
     </listitem>
@@ -612,7 +612,7 @@ CREATE EXTENSION postgres_fdw;
 </programlisting>
 
   <para>
-   Then create a foreign server using <xref linkend="sql-createserver">.
+   Then create a foreign server using <xref linkend="sql-createserver"/>.
    In this example we wish to connect to a <productname>PostgreSQL</productname> server
    on host <literal>192.83.123.89</literal> listening on
    port <literal>5432</literal>.  The database to which the connection is made
@@ -626,7 +626,7 @@ CREATE SERVER foreign_server
   </para>
 
   <para>
-   A user mapping, defined with <xref linkend="sql-createusermapping">, is
+   A user mapping, defined with <xref linkend="sql-createusermapping"/>, is
    needed as well to identify the role that will be used on the remote
    server:
 
@@ -639,7 +639,7 @@ CREATE USER MAPPING FOR local_user
 
   <para>
    Now it is possible to create a foreign table with
-   <xref linkend="sql-createforeigntable">.  In this example we
+   <xref linkend="sql-createforeigntable"/>.  In this example we
    wish to access the table named <structname>some_schema.some_table</structname>
    on the remote server.  The local name for it will
    be <structname>foreign_table</structname>:
@@ -658,7 +658,7 @@ CREATE FOREIGN TABLE foreign_table (
    Column names must match as well, unless you attach <literal>column_name</literal>
    options to the individual columns to show how they are named in the remote
    table.
-   In many cases, use of <xref linkend="sql-importforeignschema"> is
+   In many cases, use of <xref linkend="sql-importforeignschema"/> is
    preferable to constructing foreign table definitions manually.
   </para>
  </sect2>