Editorialize a bit on the recent patch, reverting to the original versions

of the text where appropiate.

doc/src/sgml/external-projects.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.11 2006/08/01 00:09:06 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.12 2006/08/01 19:17:18 alvherre Exp $ -->
 
  <appendix id="external-projects">
   <title>PgFoundry and External Projects</title>
@@ -22,13 +22,13 @@
 
   <para>
    Secondly, many <productname>PostgreSQL</productname>-related projects are
-   still hosted at <ulink url="http://gborg.postgresql.org"><productname>GBorg</></ulink>. 
+   still hosted at <ulink url="http://gborg.postgresql.org/"><productname>GBorg</></ulink>. 
    GBorg is the original external community developer site, and while it is 
    currently closed to new projects in favor of PgFoundry, it still contains 
    many active and relevant projects. There are other popular <productname>PostgreSQL</productname> 
    related projects that are hosted independently as well at other community 
-   sites such as <ulink url="http://www.sf.net">SourceForge</ulink>. You should 
-   google if you don't find the project you are looking for.
+   sites such as <ulink url="http://www.sf.net/">SourceForge</ulink>. You should 
+   search the web if you don't find the project you are looking for.
   </para>
 
  <sect1 id="external-interfaces">
@@ -41,10 +41,11 @@
   <para>
    <productname>PostgreSQL</productname> includes very few interfaces
    with the base distribution. <application>libpq</> is packaged because
-   it is the primary dependecy of most interfaces available to PostgreSQL.
-   We also package <application>ecpg</> because it is tied to the 
-   server-side grammar. All other interfaces, such as PHP, Perl, Python,
-   and Ruby, are external projects.
+   it is the primary <application>C</> interface and many other interfaces
+   are build on top of it.  <application>ecpg</> is also packaged because it is
+   tied to the server-side grammar so is very dependent on the database
+   version. All the other interfaces, such as ODBC, Java, Perl, Python, and
+   others, are external projects and must be installed separately.
   </para>
 
   <para>
@@ -72,7 +73,7 @@
     </varlistentry>
 
     <varlistentry>
-     <term>pgjdbc</term>
+     <term>PostgreSQL JDBC Driver</term>
      <listitem>
       <para>
        A <application>JDBC</> interface.
@@ -85,7 +86,7 @@
      <term>Npgsql</term>
      <listitem>
       <para>
-       <application>.Net</> interface for more recent <application>mono/C#</> applications.
+       <application>.Net</> data provider for <application>C#</> applications.
        <ulink url="http://pgfoundry.org/projects/npgsql/">Website.</ulink>
       </para>
      </listitem>
@@ -95,7 +96,7 @@
      <term>libpqxx</term>
      <listitem>
       <para>
-       A newer <application>C++</> interface.
+       A <application>C++</> interface.
        <ulink url="http://thaiopensource.org/development/libpqxx/">Website.</ulink>
       </para>
      </listitem>
@@ -115,14 +116,14 @@
      <term>pgtclng</term>
      <listitem>
       <para>
-       A newer version of the <application>Tcl</> interface.
+       A <application>Tcl</> interface.
        <ulink url="http://gborg.postgresql.org/project/pgtclng/projdisplay.php">Website.</ulink>
       </para>
      </listitem>
     </varlistentry>
 
     <varlistentry>
-     <term>Pyscopg</term>
+     <term>pyscopg</term>
      <listitem>
       <para>
        A <application>Python</> interface library that is DB API 2.0 compliant.

doc/src/sgml/maintenance.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.57 2006/08/01 00:09:06 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.58 2006/08/01 19:17:17 alvherre Exp $ -->
 
 <chapter id="maintenance">
  <title>Routine Database Maintenance Tasks</title>
@@ -8,39 +8,48 @@
  </indexterm>
 
  <indexterm zone="maintenance">
-  <primary>Routine maintenance</primary>
+  <primary>routine maintenance</primary>
  </indexterm>
 
   <para>
-   PostgreSQL, like any database software, requires that certain tasks
+   <productname>PostgreSQL</>, like any database software, requires that certain tasks
    be performed regularly to achieve optimum performance. The tasks
    discussed here are <emphasis>required</emphasis>, but they
    are repetitive in nature and can easily be automated using standard
-   Unix tools such as <application>cron</application> scripts.  
+   Unix tools such as <application>cron</application> scripts or
+   Windows' <application>Task Scheduler</>.  But it is the database
+   administrator's responsibility to set up appropriate scripts, and to
+   check that they execute successfully.
   </para>
 
   <para>
-   <productname>PostgreSQL</productname> is low-maintenance compared
-   to other database management systems. It is also fairly easy, provided
-   you read the documentation.
+   One obvious maintenance task is creation of backup copies of the data on a
+   regular schedule.  Without a recent backup, you have no chance of recovery
+   after a catastrophe (disk failure, fire, mistakenly dropping a critical
+   table, etc.).  The backup and recovery mechanisms available in
+   <productname>PostgreSQL</productname> are discussed at length in
+   <xref linkend="backup">.
   </para>
 
   <para>
-   There are three tasks that <emphasis>must</emphasis> be performed on 
-   a periodic basis. The first is backups. If you do not have a current backup
-   and your system experiences a catastrophic failure, you will lose your data.
-   You can read further about backups procedures in <xref linkend="backup">. 
-   The second is vacuum which is discussed in <xref linkend="routine-vacuuming">. 
-   The third is to update the planner statistics using the analyze command as 
-   discussed in <xref linkend="vacuum-for-statistics">.
+   The other main category of maintenance task is periodic <quote>vacuuming</>
+   of the database.  This activity is discussed in
+   <xref linkend="routine-vacuuming">.  Closely related to this is to update
+   the statistics that will be used by the query planner, as discussed in
+   <xref linkend="vacuum-for-statistics">.
   </para>
 
   <para>
-   Another task that may need periodic attention is log file management.
+   Another task that might need periodic attention is log file management.
    This is discussed in <xref linkend="logfile-maintenance">.
   </para>
 
-  
+  <para>
+   <productname>PostgreSQL</productname> is low-maintenance compared
+   to some other database management systems.  Nonetheless,
+   appropriate attention to these tasks will go far towards ensuring a
+   pleasant and productive experience with the system.
+  </para>
 
  <sect1 id="routine-vacuuming">
   <title>Routine Vacuuming</title>
@@ -80,12 +89,13 @@
   </para>
 
   <para>
-   The standard form of <command>VACUUM</> does not intefere with production
-   database operations. Items such as SELECTS, INSERTS, UPDATES and DELETES
+   The standard form of <command>VACUUM</> can run in parallel with production
+   database operations. Commands such as SELECTs, INSERTs, UPDATEs and DELETEs
    will continue to function as normal, though you will not be able to modify the
-   definition (Such as ALTER TABLE ADD COLUMN) of a table while it is being vacuumed.
-   The release of <productname>PostgreSQL</productname> 8.0, introduced new
-   configuration parameters to further reduce the potentially negative 
+   definition of a table with commands such as ALTER TABLE ADD COLUMN
+   while it is being vacuumed.
+   Beginning in <productname>PostgreSQL</productname> 8.0, there are
+   configuration parameters that can be adjusted to further reduce the
    performance impact of background vacuuming.  See
    <xref linkend="runtime-config-resource-vacuum-cost">.
   </para>
@@ -187,8 +197,8 @@
 
    <para>
     If you have a table whose entire contents are deleted on a periodic
-    basis, consider doing it with the <command>TRUNCATE</command> rather
-    than using the <command>DELETE</command> followed by
+    basis, consider doing it with <command>TRUNCATE</command> rather
+    than using <command>DELETE</command> followed by
     <command>VACUUM</command>. <command>TRUNCATE</command> removes the
     entire content of the table immediately, without requiring a
     subsequent <command>VACUUM</command> or <command>VACUUM