Update contrib documention mentions to point to actual documentation

bmomjian · bmomjian · commit 159e3d86292c · 2011-01-26T09:22:21.000-05:00
sections, rather than just calling it "/contrib/module_name".

Also update pg_test_fsync build instructions now that it is in /contrib.
diff --git a/doc/src/sgml/contrib-spi.sgml b/doc/src/sgml/contrib-spi.sgml
@@ -9,7 +9,7 @@
  </indexterm>
 
  <para>
-  The <filename>contrib/spi</> module provides several workable examples
+  The <application>spi</> module provides several workable examples
   of using SPI and triggers.  While these functions are of some value in
   their own right, they are even more useful as examples to modify for
   your own purposes.  The functions are general enough to be used
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
@@ -3917,9 +3917,9 @@ a0ee-bc99-9c0b-4ef8-bb6d-6bb9-bd38-0a11
     <productname>PostgreSQL</productname> provides storage and comparison
     functions for UUIDs, but the core database does not include any
     function for generating UUIDs, because no single algorithm is well
-    suited for every application.  The contrib module
-    <filename>contrib/uuid-ossp</filename> provides functions that implement
-    several standard algorithms.
+    suited for every application.  The <xref
+    linkend="uuid-ossp"> module
+    provides functions that implement several standard algorithms.
     Alternatively, UUIDs could be generated by client applications or
     other libraries invoked through a server-side function.
    </para>
diff --git a/doc/src/sgml/dblink.sgml b/doc/src/sgml/dblink.sgml
@@ -303,7 +303,7 @@ SELECT dblink_disconnect('myconn');
   </refsect1>
  </refentry>
 
- <refentry id="CONTRIB-DBLINK">
+ <refentry id="CONTRIB-DBLINK-FUNCTION">
   <refmeta>
    <refentrytitle>dblink</refentrytitle>
    <manvolnum>3</manvolnum>
diff --git a/doc/src/sgml/diskusage.sgml b/doc/src/sgml/diskusage.sgml
@@ -31,10 +31,9 @@
   <para>
    You can monitor disk space in three ways:
    using the SQL functions listed in <xref linkend="functions-admin-dbsize">,
-   using the tools in <filename>contrib/oid2name</>, or
+   using the <xref linkend="oid2name"> module, or
    using manual inspection of the system catalogs.
    The SQL functions are the easiest to use and are generally recommended.
-   <filename>contrib/oid2name</> is described in <xref linkend="oid2name">.
    The remainder of this section shows how to do it by inspection of the
    system catalogs.
   </para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
@@ -966,8 +966,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     sections is to use a <varname>restore_command</> that polls the archive location.
     This was the only option available in versions 8.4 and below. In this
     setup, set <varname>standby_mode</> off, because you are implementing
-    the polling required for standby operation yourself. See
-    contrib/pg_standby (<xref linkend="pgstandby">) for a reference
+    the polling required for standby operation yourself. See the
+    <xref linkend="pgstandby"> module for a reference
     implementation of this.
    </para>
 
@@ -1027,7 +1027,7 @@ if (!triggered)
 
    <para>
     A working example of a waiting <varname>restore_command</> is provided
-    as a <filename>contrib</> module named <application>pg_standby</>. It
+    in the <xref linkend="pgstandby"> module. It
     should be used as a reference on how to correctly implement the logic
     described above. It can also be extended as needed to support specific
     configurations and environments.
@@ -1542,7 +1542,7 @@ if (!triggered)
     primary server and keep a query active for as long as needed to
     run queries on the standby. This prevents <command>VACUUM</> from removing
     recently-dead rows and so cleanup conflicts do not occur.
-    This could be done using <filename>contrib/dblink</> and
+    This could be done using <xref linkend="dblink"> and
     <function>pg_sleep()</>, or via other mechanisms. If you do this, you
     should note that this will delay cleanup of dead rows on the primary,
     which may result in undesirable table bloat. However, the cleanup
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
@@ -1007,8 +1007,8 @@ su - postgres
        <listitem>
         <para>
          Use the <ulink url="http://www.ossp.org/pkg/lib/uuid/">OSSP UUID
-         library</ulink> when building <filename>contrib/uuid-ossp</>.
-         The library provides functions to generate
+         library</ulink> when building the <xref linkend="uuid-ossp">
+         module.  The library provides functions to generate
          UUIDs.<indexterm><primary>UUID</primary></indexterm>
         </para>
        </listitem>
@@ -1041,9 +1041,9 @@ su - postgres
        <term><option>--with-libxslt</option></term>
        <listitem>
         <para>
-         Use libxslt when building <filename>contrib/xml2</>.
-         <filename>contrib/xml2</> relies on this library to perform
-         XSL transformations of XML.
+         Use libxslt when building the <xref linkend="xml2">
+         module.  <application>xml2</> relies on this library
+         to perform XSL transformations of XML.
         </para>
        </listitem>
       </varlistentry>
diff --git a/doc/src/sgml/lo.sgml b/doc/src/sgml/lo.sgml
@@ -99,7 +99,7 @@ CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
 
     <para>
      If you already have, or suspect you have, orphaned large objects, see the
-     <filename>contrib/vacuumlo</> module (<xref linkend="vacuumlo">) to help
+     <xref linkend="vacuumlo"> module to help
      you clean them up.  It's a good idea to run <application>vacuumlo</>
      occasionally as a back-stop to the <function>lo_manage</> trigger.
     </para>
diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml
@@ -686,8 +686,9 @@ SELECT *
       AS t1(proname name, prosrc text)
     WHERE proname LIKE 'bytea%';
 </programlisting>
-     The <literal>dblink</> function executes a remote query (see
-     <filename>contrib/dblink</>).  It is declared to return
+     The <xref linkend="CONTRIB-DBLINK-FUNCTION"> function
+     (part of the <xref linkend="dblink"> module>) executes
+     a remote query.  It is declared to return
      <type>record</> since it might be used for any kind of query.
      The actual column set must be specified in the calling query so
      that the parser knows, for example, what <literal>*</> should
diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml
@@ -92,9 +92,8 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"'  # Windows
         may be safely removed.
         This information can be used to truncate the archive to just the
         minimum required to support restart from the current restore.
-        The <application>pg_archivecleanup</> utility provided in
-        <literal>contrib</> (see <xref linkend="pgarchivecleanup">) serves as a
-        convenient target for <varname>archive_cleanup_command</> in typical
+        The <xref linkend="pgarchivecleanup"> module
+        is often used in <varname>archive_cleanup_command</> for
         single-standby configurations, for example:
 <programlisting> archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r' </programlisting>
         Note however that if multiple standby servers are restoring from the
diff --git a/doc/src/sgml/ref/create_opclass.sgml b/doc/src/sgml/ref/create_opclass.sgml
@@ -276,8 +276,8 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
 
   <para>
    The following example command defines a GiST index operator class
-   for the data type <literal>_int4</> (array of <type>int4</type>).  See
-   <filename>contrib/intarray/</> for the complete example.
+   for the data type <literal>_int4</> (array of <type>int4</type>).  See the
+   <xref linkend="intarray"> module for the complete example.
   </para>
 
 <programlisting>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
@@ -1502,9 +1502,8 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
 
    <listitem>
     <para>
-     The <filename>contrib</> function library
-     <link linkend="pgcrypto"><function>pgcrypto</function></link>
-     allows certain fields to be stored encrypted.
+     The <xref linkend="pgcrypto"> module allows certain fields to be
+     stored encrypted.
      This is useful if only some of the data is sensitive.
      The client supplies the decryption key and the data is decrypted
      on the server and then sent to the client.
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
@@ -3939,8 +3939,8 @@ INSERT INTO a SELECT * FROM a;
    using <function>SPI_exec</function> and returns the number of rows
    that were processed by the command.  You can find more complex
    examples for SPI in the source tree in
-   <filename>src/test/regress/regress.c</filename> and in
-   <filename>contrib/spi</filename>.
+   <filename>src/test/regress/regress.c</filename> and in the
+   <xref linkend="contrib-spi"> module.
   </para>
 
 <programlisting>
diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
@@ -455,8 +455,8 @@ at the root.
 <para>
 See <filename>src/backend/storage/freespace/README</> for more details on
 how the <acronym>FSM</> is structured, and how it's updated and searched.
-The <filename>contrib/pg_freespacemap</> module can be used to examine the
-information stored in free space maps (see <xref linkend="pgfreespacemap">).
+The <xref linkend="pgfreespacemap"> module
+can be used to examine the information stored in free space maps.
 </para>
 
 </sect1>
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
@@ -2132,9 +2132,7 @@ ALTER TEXT SEARCH CONFIGURATION astro_en
    end where it'd be useless.  Filtering dictionaries are useful to partially
    normalize words to simplify the task of later dictionaries.  For example,
    a filtering dictionary could be used to remove accents from accented
-   letters, as is done by the
-   <link linkend="unaccent"><filename>contrib/unaccent</></link>
-   extension module.
+   letters, as is done by the <xref linkend="unaccent"> module.
   </para>
 
   <sect2 id="textsearch-stopwords">
@@ -3367,8 +3365,8 @@ CREATE INDEX <replaceable>name</replaceable> ON <replaceable>table</replaceable>
    allows the implementation of very fast searches with online update.
    Partitioning can be done at the database level using table inheritance,
    or by distributing documents over
-   servers and collecting search results using the <filename>contrib/dblink</>
-   extension module. The latter is possible because ranking functions use
+   servers and collecting search results using the <xref linkend="dblink">
+   module. The latter is possible because ranking functions use
    only local information.
   </para>
 
@@ -3616,8 +3614,9 @@ Parser: "pg_catalog.default"
   <title>Migration from Pre-8.3 Text Search</title>
 
   <para>
-   Applications that used the <filename>contrib/tsearch2</> add-on module
-   for text searching will need some adjustments to work with the
+   Applications that use the <xref linkend="tsearch2">
+   module for text searching will need some adjustments to work
+   with the
    built-in features:
   </para>
 
@@ -3628,19 +3627,19 @@ Parser: "pg_catalog.default"
      argument lists, and all of them are now in the <literal>pg_catalog</>
      schema, whereas in a previous installation they would have been in
      <literal>public</> or another non-system schema.  There is a new
-     version of <filename>contrib/tsearch2</> (see <xref linkend="tsearch2">)
+     version of <application>tsearch2</>
      that provides a compatibility layer to solve most problems in this
      area.
     </para>
    </listitem>
 
    <listitem>
     <para>
-     The old <filename>contrib/tsearch2</> functions and other objects
+     The old <application>tsearch2</> functions and other objects
      <emphasis>must</> be suppressed when loading <application>pg_dump</>
      output from a pre-8.3 database.  While many of them won't load anyway,
      a few will and then cause problems.  One simple way to deal with this
-     is to load the new <filename>contrib/tsearch2</> module before restoring
+     is to load the new <application>tsearch2</> module before restoring
      the dump; then it will block the old objects from being loaded.
     </para>
    </listitem>
diff --git a/doc/src/sgml/trigger.sgml b/doc/src/sgml/trigger.sgml
@@ -832,7 +832,7 @@ DELETE 2
    <para>
     There are more complex examples in
     <filename>src/test/regress/regress.c</filename> and
-    in <filename>contrib/spi</filename>.
+    in <xref linkend="contrib-spi">.
    </para>
   </sect1>
  </chapter>
diff --git a/doc/src/sgml/tsearch2.sgml b/doc/src/sgml/tsearch2.sgml
@@ -8,9 +8,9 @@
  </indexterm>
 
  <para>
-  The <literal>tsearch2</literal> module provides backwards-compatible
+  The <application>tsearch2</> module provides backwards-compatible
   text search functionality for applications that used
-  <filename>contrib/tsearch2</> before text searching was integrated
+  <application>tsearch2</> before text searching was integrated
   into core <productname>PostgreSQL</productname> in release 8.3.
  </para>
 
@@ -19,7 +19,7 @@
 
   <para>
    Although the built-in text search features were based on
-   <filename>contrib/tsearch2</> and are largely similar to it,
+   <application>tsearch2</> and are largely similar to it,
    there are numerous small differences that will create portability
    issues for existing applications:
   </para>
@@ -38,7 +38,7 @@
     <para>
      The built-in text search data types and functions all exist within
      the system schema <literal>pg_catalog</>.  In an installation using
-     <filename>contrib/tsearch2</>, these objects would usually have been in
+     <application>tsearch2</>, these objects would usually have been in
      the <literal>public</> schema, though some users chose to place them
      in a separate schema of their own.  Explicitly schema-qualified
      references to the objects will therefore fail in either case.
@@ -86,7 +86,7 @@
     <para>
      Text search configuration information has been moved into core
      system catalogs that are noticeably different from the tables used
-     by <filename>contrib/tsearch2</>.  Any applications that examined
+     by <application>tsearch2</>.  Any applications that examined
      or modified those tables will need adjustment.
     </para>
    </listitem>
@@ -98,7 +98,7 @@
      catalogs using the new text search configuration SQL commands.
      The replacement <literal>tsearch2</literal> module offers a little
      bit of support for this by making it possible to load an old set
-     of <filename>contrib/tsearch2</> configuration tables into
+     of <application>tsearch2</> configuration tables into
      <productname>PostgreSQL</productname> 8.3.  (Without the module,
      it is not possible to load the configuration data because values in the
      <type>regprocedure</> columns cannot be resolved to functions.)
@@ -132,7 +132,7 @@
 
   <para>
    The recommended way to update a pre-8.3 installation that uses
-   <filename>contrib/tsearch2</> is:
+   <application>tsearch2</> is:
   </para>
 
   <procedure>
@@ -150,7 +150,7 @@
      the replacement <literal>tsearch2</literal> module into each
      database that will use text search.  This must be done
      <emphasis>before</> loading the dump data!  If your old installation
-     had the <filename>contrib/tsearch2</> objects in a schema other
+     had the <application>tsearch2</> objects in a schema other
      than <literal>public</>, be sure to adjust the
      <literal>tsearch2</literal> installation script so that the replacement
      objects are created in that same schema.
@@ -160,7 +160,7 @@
    <step>
     <para>
      Load the dump data.  There will be quite a few errors reported
-     due to failure to recreate the original <filename>contrib/tsearch2</>
+     due to failure to recreate the original <application>tsearch2</>
      objects.  These errors can be ignored, but this means you cannot
      restore the dump in a single transaction (eg, you cannot use
      <application>pg_restore</>'s <literal>-1</> switch).
@@ -169,7 +169,7 @@
 
    <step>
     <para>
-     Examine the contents of the restored <filename>contrib/tsearch2</>
+     Examine the contents of the restored <application>tsearch2</>
      configuration tables (<structname>pg_ts_cfg</> and so on), and
      create equivalent built-in text search configurations as needed.
      You may drop the old configuration tables once you've extracted
diff --git a/doc/src/sgml/vacuumlo.sgml b/doc/src/sgml/vacuumlo.sgml
@@ -17,7 +17,7 @@
 
  <para>
   If you use this, you may also be interested in the <function>lo_manage</>
-  trigger in <filename>contrib/lo</> (see <xref linkend="lo">).
+  trigger in the <xref linkend="lo"> module.
   <function>lo_manage</> is useful to try
   to avoid creating orphaned LOs in the first place.
  </para>
diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
@@ -129,8 +129,8 @@
    file systems behave suboptimally when combined with battery-backup unit
    (<acronym>BBU</>) disk controllers.  In such setups, the synchronize
    command forces all data from the controller cache to the disks,
-   eliminating much of the benefit of the BBU.  You can run the utility
-   <filename>contrib/pg_test_fsync</> in the PostgreSQL source tree to see
+   eliminating much of the benefit of the BBU.  You can run the
+   <xref linkend="pgtestfsync"> module to see
    if you are affected.  If you are affected, the performance benefits
    of the BBU can be regained by turning off write barriers in
    the file system or reconfiguring the disk controller, if that is
@@ -571,8 +571,8 @@
    the exception of <literal>fsync_writethrough</>, which can sometimes
    force a flush of the disk cache even when other options do not do so.
    However, it's quite platform-specific which one will be the fastest;
-   you can test option speeds using the utility <filename>contrib/pg_test_fsync</>
-   in the PostgreSQL source tree.
+   you can test option speeds using the <xref
+   linkend="pgtestfsync"> module.
    Note that this parameter is irrelevant if <varname>fsync</varname>
    has been turned off.
   </para>
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
@@ -3231,8 +3231,9 @@ CREATE OR REPLACE FUNCTION retcomposite(IN integer, IN integer,
     </para>
 
     <para>
-     The directory <filename>contrib/tablefunc</> in the source
-     distribution contains more examples of set-returning functions.
+     The directory <link linkend="tablefunc">contrib/tablefunc</>
+     module in the source distribution contains more examples of
+     set-returning functions.
     </para>
    </sect2>
 
