Spell checker run

Author: petere

doc/src/sgml/array.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.40 2004/11/27 21:27:05 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.41 2004/12/13 18:05:07 petere Exp $ -->
 
 <sect1 id="arrays">
  <title>Arrays</title>
@@ -547,8 +547,8 @@ SELECT * FROM sal_emp WHERE 10000 = ALL (pay_by_quarter);
    equal to one, an additional decoration that indicates the actual
    array dimensions will precede the array structure decoration.
    The decoration consists of square braces (<literal>[</> and <literal>]</>)
-   around each array dimension's lower and upper bound indicies, plus
-   a colon (<literal>:</>) delimiter character inbetween. Delimiting the
+   around each array dimension's lower and upper bound indices, plus
+   a colon (<literal>:</>) delimiter character in between. Delimiting the
    array dimension decoration from the array structure decoration is a
    single assignment operator (<literal>=</>). For example:
 <programlisting>
@@ -569,7 +569,7 @@ SELECT ARRAY[1,2] || ARRAY[[3,4]] AS array;
   </para>
 
   <para>
-   In a similar fashion, an array with non-default indicies may be specified
+   In a similar fashion, an array with non-default indices may be specified
    using the same literal syntax. For example:
 <programlisting>
 SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2

doc/src/sgml/backup.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.52 2004/11/17 18:29:02 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.53 2004/12/13 18:05:07 petere Exp $
 -->
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -317,7 +317,7 @@ tar -cf backup.tar /usr/local/pgsql/data
       get a usable backup. Half-way measures such as disallowing all
       connections will <emphasis>not</emphasis> work
       (mainly because <command>tar</command> and similar tools do not take an
-      atomic snapshot of the state of the filesystem at a point in
+      atomic snapshot of the state of the file system at a point in
       time). Information about stopping the server can be found in
       <xref linkend="postmaster-shutdown">.  Needless to say that you
       also need to shut down the server before restoring the data.
@@ -365,7 +365,7 @@ tar -cf backup.tar /usr/local/pgsql/data
    If your database is spread across multiple volumes (for example,
    data files and WAL log on different disks) there may not be any way
    to obtain exactly-simultaneous frozen snapshots of all the volumes.
-   Read your filesystem documentation very carefully before trusting
+   Read your file system documentation very carefully before trusting
    to the consistent-snapshot technique in such situations.
   </para>
 
@@ -402,7 +402,7 @@ tar -cf backup.tar /usr/local/pgsql/data
    database can be restored to consistency by <quote>replaying</> the
    log entries made since the last checkpoint.  However, the existence
    of the log makes it possible to use a third strategy for backing up
-   databases: we can combine a filesystem-level backup with backup of
+   databases: we can combine a file-system-level backup with backup of
    the WAL files.  If recovery is needed, we restore the backup and
    then replay from the backed-up WAL files to bring the backup up to
    current time.  This approach is more complex to administer than
@@ -414,7 +414,7 @@ tar -cf backup.tar /usr/local/pgsql/data
      We do not need a perfectly consistent backup as the starting point.
      Any internal inconsistency in the backup will be corrected by log
      replay (this is not significantly different from what happens during
-     crash recovery).  So we don't need filesystem snapshot capability,
+     crash recovery).  So we don't need file system snapshot capability,
      just <application>tar</> or a similar archiving tool.
     </para>
    </listitem>
@@ -449,7 +449,7 @@ tar -cf backup.tar /usr/local/pgsql/data
   </para>
 
   <para>
-   As with the plain filesystem-backup technique, this method can only
+   As with the plain file-system-backup technique, this method can only
    support restoration of an entire database cluster, not a subset.
    Also, it requires a lot of archival storage: the base backup may be bulky,
    and a busy system will generate many megabytes of WAL traffic that
@@ -618,7 +618,7 @@ archive_command = 'test ! -f .../%f &amp;&amp; cp %p .../%f'
     <filename>postgresql.conf</>, <filename>pg_hba.conf</> and
     <filename>pg_ident.conf</>) after the initial base backup.
     You may wish to keep the configuration files in a location that will
-    be backed up by your regular filesystem backup procedures.
+    be backed up by your regular file system backup procedures.
    </para>
   </sect2>
 
@@ -655,7 +655,7 @@ SELECT pg_start_backup('label');
    </listitem>
    <listitem>
     <para>
-     Perform the backup, using any convenient filesystem-backup tool
+     Perform the backup, using any convenient file-system-backup tool
      such as <application>tar</> or <application>cpio</>.  It is neither
      necessary nor desirable to stop normal operation of the database
      while you do this.
@@ -867,7 +867,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
     It is important that the command return nonzero exit status on failure.
     The command <emphasis>will</> be asked for log files that are not present
     in the archive; it must return nonzero when so asked.  This is not an
-    error condition.  Be aware also that the basename of the <literal>%p</>
+    error condition.  Be aware also that the base name of the <literal>%p</>
     path will be different from <literal>%f</>; do not expect them to be
     interchangeable.
    </para>
@@ -948,7 +948,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
       </term>
       <listitem>
        <para>
-        This parameter specifies the timestamp up to which recovery
+        This parameter specifies the time stamp up to which recovery
         will proceed.
         At most one of <varname>recovery_target_time</> and
         <xref linkend="recovery-target-xid"> can be specified.
@@ -1098,7 +1098,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
   <itemizedlist>
    <listitem>
     <para>
-     Operations on non-btree indexes (hash, R-tree, and GiST indexes) are
+     Operations on non-B-tree indexes (hash, R-tree, and GiST indexes) are
      not presently WAL-logged, so replay will not update these index types.
      The recommended workaround is to manually <command>REINDEX</> each
      such index after completing a recovery operation.
@@ -1196,7 +1196,7 @@ psql template1 < backup
 
   <para>
    You will always need a SQL dump (<application>pg_dump</> dump) for
-   migrating to a new release.  Filesystem-level backups (including
+   migrating to a new release.  File-system-level backups (including
    on-line backups) will not work, for the same reason that you can't
    just do the update in-place: the file formats won't necessarily be
    compatible across major releases.

doc/src/sgml/catalogs.sgml

@@ -1,6 +1,6 @@
 <!--
  Documentation of the system catalogs, directed toward PostgreSQL developers
- $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.93 2004/12/01 19:00:27 tgl Exp $
+ $PostgreSQL: pgsql/doc/src/sgml/catalogs.sgml,v 2.94 2004/12/13 18:05:07 petere Exp $
  -->
 
 <chapter id="catalogs">
@@ -980,7 +980,7 @@
    represents converting from one type to another and applying a length
    coercion in a single step.  When no such entry is available, coercion
    to a type that uses a type modifier involves two steps, one to
-   convert between datatypes and a second to apply the modifier.
+   convert between data types and a second to apply the modifier.
   </para>
  </sect1>
 
@@ -1037,7 +1037,7 @@
       <entry><type>oid</type></entry>
       <entry><literal><link linkend="catalog-pg-type"><structname>pg_type</structname></link>.oid</literal></entry>
       <entry>
-       The OID of the data type that corresponds to this table's rowtype,
+       The OID of the data type that corresponds to this table's row type,
        if any (zero for indexes, which have no <structname>pg_type</> entry)
       </entry>
      </row>
@@ -2010,7 +2010,7 @@
      <row>
       <entry><structfield>indclass</structfield></entry>
       <entry><type>oidvector</type></entry>
-      <entry><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</entry>
+      <entry><literal><link linkend="catalog-pg-opclass"><structname>pg_opclass</structname></link>.oid</literal></entry>
       <entry>
        For each column in the index key this contains the OID of
        the operator class to use.  See

doc/src/sgml/ddl.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.33 2004/11/27 21:27:06 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.34 2004/12/13 18:05:08 petere Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -1148,7 +1148,7 @@ WHERE c.altitude &gt; 500 and c.tableoid = p.oid;
       <literal>UNIQUE</> or a <literal>PRIMARY KEY</>, this would not stop the
       <structname>capitals</> table from having rows with names duplicating
       rows in <structname>cities</>.  And those duplicate rows would by
-      default show up in SELECTs from <structname>cities</>.  In fact, by
+      default show up in queries from <structname>cities</>.  In fact, by
       default <structname>capitals</> would have no unique constraint at all,
       and so could contain multiple rows with the same name.
       You could add a unique constraint to <structname>capitals</>, but this

doc/src/sgml/external-projects.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.5 2004/12/13 18:05:08 petere Exp $
 -->
 
  <chapter id="external-projects">
@@ -43,16 +43,6 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
    popular interfaces are:
 
    <variablelist>
-    <varlistentry>
-     <term>ODBC</term>
-     <listitem>
-      <para>
-       This is the most common interface for <application>Windows</>
-       applications.
-      </para>
-     </listitem>
-    </varlistentry>
-
     <varlistentry>
      <term>psqlODBC</term>
      <listitem>
@@ -155,7 +145,7 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
    separate projects. <application>pgFoundry</> at <ulink
    url="http://pgfoundry.org">http://pgfoundry.org</ulink> contains
    even more projects. Other projects are not even hosted on these
-   servers and you will have to do an internet search to find them.
+   servers and you will have to do an Internet search to find them.
   </para>
 
  </sect1>
@@ -171,21 +161,21 @@ $PostgreSQL: pgsql/doc/src/sgml/external-projects.sgml,v 1.4 2004/12/03 06:30:40
    <productname>PostgreSQL</> was designed from the start to be
    extensible. For this reason, extensions loaded into the database can
    function just like features that are packaged with the database. The
-   <filename>/contrib</> directory shipped with the source code
+   <filename>contrib/</> directory shipped with the source code
    contains a large number of extensions. The <filename>README</> file
    in that directory contains a summary. They include conversion tools,
    full-text indexing, <acronym>XML</> tools, and additional data types
    and indexing methods. Other extensions are developed independently,
    like <application>PostGIS</>. Even <application>PostgreSQL</>
    replication solutions are developed externally. For example,
-   <application>Slony</> is a popular master/slave replication solution
+   <application>Slony-I</> is a popular master/slave replication solution
    that is developed independently from the main projects.
   </para>
 
   <para>
    There are several administration tools available for
    <productname>PostgreSQL</>. The most popular is
-   <application>pgadmin</>, and there are several commercially
+   <application>pgAdmin</>, and there are several commercially
    available ones.
   </para> 
 

doc/src/sgml/func.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.229 2004/12/03 18:34:31 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.230 2004/12/13 18:05:08 petere Exp $
 PostgreSQL documentation
 -->
 
@@ -8553,7 +8553,7 @@ SELECT pg_type_is_visible('myschema.widget'::regtype);
       <row>
        <entry><literal><function>pg_get_serial_sequence</function>(<parameter>table_name</parameter>, <parameter>column_name</parameter>)</literal></entry>
        <entry><type>text</type></entry>
-       <entry>get name of the sequence that a serial or bigserial column
+       <entry>get name of the sequence that a <type>serial</type> or <type>bigserial</type> column
        uses</entry>
       </row>
       <row>
@@ -8801,7 +8801,7 @@ SELECT set_config('log_statement_stats', 'off', false);
     This function returns 1 if successful, 0 if not successful.
     The process ID (<literal>pid</literal>) of an active backend can be found
     from the <structfield>procpid</structfield> column in the
-    <structname>pg_stat_activity</structname> view, or by listing the postgres
+    <structname>pg_stat_activity</structname> view, or by listing the <command>postgres</command>
     processes on the server with <application>ps</>.
    </para>
 

doc/src/sgml/installation.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.211 2004/12/11 20:54:14 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.212 2004/12/13 18:05:08 petere Exp $ -->
 
 <chapter id="installation">
  <title><![%standalone-include[<productname>PostgreSQL</>]]>
@@ -173,8 +173,8 @@ su - postgres
      <para>
       To build the <application>PL/Python</> server programming
       language, you need a <productname>Python</productname>
-      installation with the header files and the distutils module.
-      The distutils module is included by default with
+      installation with the header files and the <application>distutils</application> module.
+      The <application>distutils</application> module is included by default with
       <productname>Python</productname> 1.6 and later; users of
       earlier versions of <productname>Python</productname> will need
       to install it.

doc/src/sgml/libpq.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.170 2004/12/02 15:32:52 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/libpq.sgml,v 1.171 2004/12/13 18:05:08 petere Exp $
 -->
 
  <chapter id="libpq">
@@ -1203,7 +1203,7 @@ about such errors.
 </para>
 
 <para>
-At present, there is no way to determine the actual datatype inferred for
+At present, there is no way to determine the actual data type inferred for
 any parameters whose types are not specified in <parameter>paramTypes[]</>.
 This is a <application>libpq</> omission that will probably be rectified
 in a future release.

doc/src/sgml/maintenance.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.38 2004/11/15 06:32:14 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.39 2004/12/13 18:05:08 petere Exp $
 -->
 
 <chapter id="maintenance">
@@ -183,7 +183,7 @@ $PostgreSQL: pgsql/doc/src/sgml/maintenance.sgml,v 1.38 2004/11/15 06:32:14 neil
     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 recquiring a
+    entire content of the table immediately, without requiring a
     subsequent <command>VACUUM</command> or <command>VACUUM
     FULL</command> to reclaim the now-unused disk space.
    </para>
@@ -502,7 +502,7 @@ pg_ctl start | rotatelogs /var/log/pgsql_log 86400
    just when you need them the most.  Also, on <productname>linux</>,
    <application>syslog</> will sync each message to disk, yielding poor
    performance.  (You can use a <literal>-</> at the start of the file name
-   in the <application>syslog</> config file to disable this behavior.)
+   in the <application>syslog</> configuration file to disable this behavior.)
   </para>
 
   <para>

doc/src/sgml/manage-ag.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.37 2004/12/02 19:28:48 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/manage-ag.sgml,v 2.38 2004/12/13 18:05:08 petere Exp $
 -->
 
 <chapter id="managing-databases">
@@ -379,10 +379,10 @@ CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';
    <note>
     <para>
      There is usually not much point in making more than one
-     tablespace per logical filesystem, since you cannot control the location
-     of individual files within a logical filesystem.  However,
+     tablespace per logical file system, since you cannot control the location
+     of individual files within a logical file system.  However,
      <productname>PostgreSQL</> does not enforce any such limitation, and
-     indeed it is not directly aware of the filesystem boundaries on your
+     indeed it is not directly aware of the file system boundaries on your
      system.  It just stores files in the directories you tell it to use.
     </para>
    </note>

doc/src/sgml/plperl.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.33 2004/12/11 20:03:37 petere Exp $
+$PostgreSQL: pgsql/doc/src/sgml/plperl.sgml,v 2.34 2004/12/13 18:05:08 petere Exp $
 -->
 
  <chapter id="plperl">
@@ -295,7 +295,7 @@ $$ LANGUAGE plperl;
   <para>
    Here is an example of a PL/Perl function returning a row set of a
    composite type.  Since a row set is always a reference to an array
-   and a composite type is always a reference to a hash, a rowset of a
+   and a composite type is always a reference to a hash, a row set of a
    composite type is a reference to an array of hash references.
 <programlisting>
 CREATE TYPE testsetperl AS (f1 integer, f2 text, f3 text);

doc/src/sgml/plpgsql.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.50 2004/12/03 17:12:09 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/plpgsql.sgml,v 1.51 2004/12/13 18:05:08 petere Exp $
 -->
 
 <chapter id="plpgsql"> 
@@ -2576,7 +2576,7 @@ CREATE TRIGGER emp_stamp BEFORE INSERT OR UPDATE ON emp
 
     <para>
      This example trigger ensures that any insert, update or delete of a row
-     in the emp table is recorded (i.e. audited) in the emp_audit table. 
+     in the <literal>emp</literal> table is recorded (i.e., audited) in the <literal>emp_audit</literal> table. 
      The current time and user name are stamped into the row, together with 
      the type of operation performed on it.
     </para>

doc/src/sgml/protocol.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.55 2004/11/15 06:32:14 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/protocol.sgml,v 1.56 2004/12/13 18:05:08 petere Exp $ -->
 
 <chapter id="protocol">
  <title>Frontend/Backend Protocol</title>
@@ -902,7 +902,7 @@
         The function call was completed and returned the result given
 	in the message.
 	(Note that the Function Call protocol can only handle a single
-	scalar result, not a rowtype or set of results.)
+	scalar result, not a row type or set of results.)
        </Para>
       </ListItem>
      </VarListEntry>