Subject: [PATCH] Various documentation typo/grammar fixes

From: Marti Raudsepp <[email-masked]>
Date: Mon, 25 Aug 2014 12:04:01 +0300

Hi

I ran the Topy typo-fixer (https://github.com/intgr/topy , using rules
developed for Wikipedia) over the PostgreSQL documentation directory.
Attached is a patch with hand-picked fixes that are clearly an
improvement.

There are also some changes that I didn't include that seem somewhat
opinionated, for example:
* "eg" -> "e.g."
* "etc" -> "etc."
* "the exact same" -> "exactly the same"
* "newly-received" -> "newly received"
* "recently-used" -> "recently used"

Does anyone have an opinion about these, should I also include them in
the patch?

Regards,
Marti

-- 
Sent via pgsql-docs mailing list ([email-masked])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

---

From: Kevin Grittner <[email-masked]>
Date: Mon, 25 Aug 2014 06:46:47 -0700

> opinionated, for example:

These two seem to me like they should be changed; otherwise they 
just don't look correct.

> * "the exact same" -> "exactly the same"

The old version sounds a bit colloquial to my ear, so it seems like 
it may be worth changing.  The problem is, this change doesn't seem 
like it would generally be a direct substitution; it may require a 
major reorganization of the sentence.  I think the resulting 
sentences need to be compared to see which is more clear and 
concise.

> * "recently-used" -> "recently used"

I think these depend on context.  To me, the former scans better 
when the combination of words is used as an adjective.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

---

From: Marti Raudsepp <[email-masked]>
Date: Mon, 25 Aug 2014 20:43:40 +0300

> These two seem to me like they should be changed; otherwise they

Oh, right you are; I looked it up on some grammar forums and there
seems to be no question about this. I attached these changes as patch
0002.

(For the record I'm not a native English speaker, much less using
Latin in English sentences ;)

> it may be worth changing.

> when the combination of words is used as an adjective.

Attached these as patch 0003 so someone who feels more confident can
take a look.

Regards,
Marti
From 05b48b6ce2e0cdf1edbdd76df838a4dc5cdc254a Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <[email-masked]>
Date: Mon, 25 Aug 2014 19:57:17 +0300
Subject: [PATCH 2/3] doc: Fix usages of etc., e.g., i.e., et al.

---
 doc/src/sgml/advanced.sgml    |  2 +-
 doc/src/sgml/arch-dev.sgml    |  2 +-
 doc/src/sgml/biblio.sgml      |  6 +++---
 doc/src/sgml/bki.sgml         |  4 ++--
 doc/src/sgml/config.sgml      |  4 ++--
 doc/src/sgml/datetime.sgml    |  2 +-
 doc/src/sgml/ddl.sgml         |  2 +-
 doc/src/sgml/extend.sgml      |  2 +-
 doc/src/sgml/func.sgml        |  4 ++--
 doc/src/sgml/libpq.sgml       |  8 ++++----
 doc/src/sgml/manage-ag.sgml   |  2 +-
 doc/src/sgml/plperl.sgml      |  6 +++---
 doc/src/sgml/pltcl.sgml       |  2 +-
 doc/src/sgml/protocol.sgml    | 22 +++++++++++-----------
 doc/src/sgml/ref/values.sgml  |  2 +-
 doc/src/sgml/release-7.4.sgml |  6 +++---
 doc/src/sgml/release-8.0.sgml |  6 +++---
 doc/src/sgml/release-8.1.sgml |  4 ++--
 doc/src/sgml/release-8.2.sgml |  4 ++--
 doc/src/sgml/release-8.3.sgml |  4 ++--
 doc/src/sgml/release-8.4.sgml |  2 +-
 doc/src/sgml/release-9.0.sgml |  2 +-
 doc/src/sgml/release-9.1.sgml |  2 +-
 doc/src/sgml/release-9.2.sgml |  2 +-
 doc/src/sgml/release-9.4.sgml |  2 +-
 doc/src/sgml/release-old.sgml | 14 +++++++-------
 doc/src/sgml/sources.sgml     |  4 ++--
 doc/src/sgml/syntax.sgml      |  2 +-
 doc/src/sgml/tsearch2.sgml    |  2 +-
 doc/src/sgml/xml2.sgml        |  2 +-
 30 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 1e45511..2b6ed22 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -225,7 +225,7 @@ UPDATE branches SET balance = balance + 100.00
 BEGIN;
 UPDATE accounts SET balance = balance - 100.00
     WHERE name = 'Alice';
--- etc etc
+-- etc. etc.
 COMMIT;
 </programlisting>
    </para>
diff --git a/doc/src/sgml/arch-dev.sgml b/doc/src/sgml/arch-dev.sgml
index c835e87..9daddee 100644
--- a/doc/src/sgml/arch-dev.sgml
+++ b/doc/src/sgml/arch-dev.sgml
@@ -259,7 +259,7 @@
      system catalog lookups can only be done within a transaction, and we
      do not wish to start a transaction immediately upon receiving a query
      string.  The raw parsing stage is sufficient to identify the transaction
-     control commands (<command>BEGIN</>, <command>ROLLBACK</>, etc), and
+     control commands (<command>BEGIN</>, <command>ROLLBACK</>, etc.), and
      these can then be correctly executed without any further analysis.
      Once we know that we are dealing with an actual query (such as
      <command>SELECT</> or <command>UPDATE</>), it is okay to
diff --git a/doc/src/sgml/biblio.sgml b/doc/src/sgml/biblio.sgml
index e2cd69d..12e59ea 100644
--- a/doc/src/sgml/biblio.sgml
+++ b/doc/src/sgml/biblio.sgml
@@ -22,7 +22,7 @@
 
    <biblioentry id="BOWMAN01">
     <title>The Practical <acronym>SQL</acronym> Handbook</title>
-    <titleabbrev>Bowman et al, 2001</titleabbrev>
+    <titleabbrev>Bowman et al., 2001</titleabbrev>
     <subtitle>Using SQL Variants</subtitle>
     <edition>Fourth Edition</edition>
     <authorgroup>
@@ -434,7 +434,7 @@ [email-masked]
     <title><ulink url="http://db.cs.berkeley.edu/papers/ERL-M89-82.pdf">
     A commentary on the <productname>POSTGRES</productname> rules system
     </ulink></title>
-    <titleabbrev>Stonebraker et al, 1989</titleabbrev>
+    <titleabbrev>Stonebraker et al., 1989</titleabbrev>
     <authorgroup>
      <author>
       <firstname>M.</firstname>
@@ -511,7 +511,7 @@ [email-masked]
     <title><ulink url="http://db.cs.berkeley.edu/papers/ERL-M90-36.pdf">
     On Rules, Procedures, Caching and Views in Database Systems
     </ulink></title>
-    <titleabbrev>Stonebraker et al, ACM, 1990</titleabbrev>
+    <titleabbrev>Stonebraker et al., ACM, 1990</titleabbrev>
     <authorgroup>
      <author>
       <firstname>M.</firstname>
diff --git a/doc/src/sgml/bki.sgml b/doc/src/sgml/bki.sgml
index aaf500a..39b7a7b 100644
--- a/doc/src/sgml/bki.sgml
+++ b/doc/src/sgml/bki.sgml
@@ -111,11 +111,11 @@
       When <literal>bootstrap</> is specified,
       the table will only be created on disk; nothing is entered into
       <structname>pg_class</structname>,
-      <structname>pg_attribute</structname>, etc, for it.  Thus the
+      <structname>pg_attribute</structname>, etc., for it.  Thus the
       table will not be accessible by ordinary SQL operations until
       such entries are made the hard way (with <literal>insert</>
       commands).  This option is used for creating
-      <structname>pg_class</structname> etc themselves.
+      <structname>pg_class</structname> etc. themselves.
      </para>
 
      <para>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f23e5dc..72f2a2a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3815,7 +3815,7 @@ local0.*    /var/log/postgresql
        <para>
         Example:  To keep 7 days of logs, one log file per day named
         <literal>server_log.Mon</literal>, <literal>server_log.Tue</literal>,
-        etc, and automatically overwrite last week's log with this week's log,
+        etc., and automatically overwrite last week's log with this week's log,
         set <varname>log_filename</varname> to <literal>server_log.%a</literal>,
         <varname>log_truncate_on_rotation</varname> to <literal>on</literal>, and
         <varname>log_rotation_age</varname> to <literal>1440</literal>.
@@ -5259,7 +5259,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
         alias <literal>pg_temp</><indexterm><primary>pg_temp</></>.  If it is not listed in the path then
         it is searched first (even before <literal>pg_catalog</>).  However,
         the temporary schema is only searched for relation (table, view,
-        sequence, etc) and data type names.  It is never searched for
+        sequence, etc.) and data type names.  It is never searched for
         function or operator names.
        </para>
 
diff --git a/doc/src/sgml/datetime.sgml b/doc/src/sgml/datetime.sgml
index 444b0ec..9c550c6 100644
--- a/doc/src/sgml/datetime.sgml
+++ b/doc/src/sgml/datetime.sgml
@@ -415,7 +415,7 @@
 
    <para>
     For reference purposes, a standard installation also contains files
-    <filename>Africa.txt</>, <filename>America.txt</>, etc, containing
+    <filename>Africa.txt</>, <filename>America.txt</>, etc., containing
     information about every time zone abbreviation known to be in use
     according to the <literal>zoneinfo</> timezone database.  The zone name
     definitions found in these files can be copied and pasted into a custom
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 0fcd9f8..32670a7 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1438,7 +1438,7 @@ ALTER TABLE products RENAME TO items;
    <literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>,
    <literal>EXECUTE</>, and <literal>USAGE</>.
    The privileges applicable to a particular
-   object vary depending on the object's type (table, function, etc).
+   object vary depending on the object's type (table, function, etc.).
    For complete information on the different types of privileges
    supported by <productname>PostgreSQL</productname>, refer to the
    <xref linkend="sql-grant"> reference
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index a2d4ca2..4199561 100644
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -530,7 +530,7 @@
     <para>
      An extension's <acronym>SQL</> script files can contain any SQL commands,
      except for transaction control commands (<command>BEGIN</>,
-     <command>COMMIT</>, etc) and commands that cannot be executed inside a
+     <command>COMMIT</>, etc.) and commands that cannot be executed inside a
      transaction block (such as <command>VACUUM</>).  This is because the
      script files are implicitly executed within a transaction block.
     </para>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 734ef5f..284c3ae 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -4193,7 +4193,7 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
    <para>
     A branch is zero or more <firstterm>quantified atoms</> or
     <firstterm>constraints</>, concatenated.
-    It matches a match for the first, followed by a match for the second, etc;
+    It matches a match for the first, followed by a match for the second, etc.;
     an empty branch matches the empty string.
    </para>
 
@@ -8863,7 +8863,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
 
     <para>
      In addition to the operators shown in the table, the ordinary B-tree
-     comparison operators (<literal>=</>, <literal>&lt;</>, etc) are defined
+     comparison operators (<literal>=</>, <literal>&lt;</>, etc.) are defined
      for types <type>tsvector</> and <type>tsquery</>.  These are not very
      useful for text searching but allow, for example, unique indexes to be
      built on columns of these types.
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index ef45fbf..7442195 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -2316,7 +2316,7 @@ PGresult *PQdescribePrepared(PGconn *conn, const char *stmtName);
         <structname>PGresult</> to obtain information about the parameters
         of the prepared statement, and the functions
         <function>PQnfields</function>, <function>PQfname</function>,
-        <function>PQftype</function>, etc provide information about the
+        <function>PQftype</function>, etc. provide information about the
         result columns (if any) of the statement.
        </para>
       </listitem>
@@ -2355,7 +2355,7 @@ PGresult *PQdescribePortal(PGconn *conn, const char *portalName);
         portal.  On success, a <structname>PGresult</> with status
         <literal>PGRES_COMMAND_OK</literal> is returned.  The functions
         <function>PQnfields</function>, <function>PQfname</function>,
-        <function>PQftype</function>, etc can be applied to the
+        <function>PQftype</function>, etc. can be applied to the
         <structname>PGresult</> to obtain information about the result
         columns (if any) of the portal.
        </para>
@@ -4437,7 +4437,7 @@ int PQflush(PGconn *conn);
    more rows will arrive.  (But note that it is still necessary to continue
    calling <function>PQgetResult</function> until it returns null.)  All of
    these <structname>PGresult</structname> objects will contain the same row
-   description data (column names, types, etc) that an ordinary
+   description data (column names, types, etc.) that an ordinary
    <structname>PGresult</structname> object for the query would have.
    Each object should be freed with <function>PQclear</function> as usual.
   </para>
@@ -4907,7 +4907,7 @@ typedef struct pgNotify
      <listitem>
       <para>
        0 indicates the overall copy format is textual (rows separated by
-       newlines, columns separated by separator characters, etc).  1
+       newlines, columns separated by separator characters, etc.).  1
        indicates the overall copy format is binary.  See <xref
        linkend="sql-copy"> for more information.
       </para>
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml
index 78ec509..8269438 100644
--- a/doc/src/sgml/manage-ag.sgml
+++ b/doc/src/sgml/manage-ag.sgml
@@ -387,7 +387,7 @@ dropdb <replaceable class="parameter">dbname</replaceable>
      of data files. They are dependent on metadata contained in the main
      data directory, and therefore cannot be attached to a different
      database cluster or backed up individually.  Similarly, if you lose
-     a tablespace (file deletion, disk failure, etc), the database cluster
+     a tablespace (file deletion, disk failure, etc.), the database cluster
      might become unreadable or unable to start.  Placing a tablespace
      on a temporary file system like a ramdisk risks the reliability of
      the entire cluster.
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 9117769..3259b29 100644
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
@@ -572,7 +572,7 @@ SELECT * from lotsa_md5(500);
     <para>
     <literal>spi_prepare</literal>, <literal>spi_query_prepared</literal>, <literal>spi_exec_prepared</literal>,
     and <literal>spi_freeplan</literal> implement the same functionality but for prepared queries.
-    <literal>spi_prepare</literal> accepts a query string with numbered argument placeholders ($1, $2, etc)
+    <literal>spi_prepare</literal> accepts a query string with numbered argument placeholders ($1, $2, etc.)
     and a string list of argument types:
 <programlisting>
 $plan = spi_prepare('SELECT * FROM test WHERE id &gt; $1 AND name = $2',
@@ -617,7 +617,7 @@ SELECT done();
  2005-12-10 | 2005-12-11 | 2005-12-12
 </programlisting>
     Note that the parameter subscript in <literal>spi_prepare</literal> is defined via
-    $1, $2, $3, etc, so avoid declaring query strings in double quotes that might easily
+    $1, $2, $3, etc., so avoid declaring query strings in double quotes that might easily
     lead to hard-to-catch bugs.
     </para>
 
@@ -942,7 +942,7 @@ $$ LANGUAGE plperl;
    PL/Perl functions will share the same value of <varname>%_SHARED</varname>
    if and only if they are executed by the same SQL role.  In an application
    wherein a single session executes code under multiple SQL roles (via
-   <literal>SECURITY DEFINER</> functions, use of <command>SET ROLE</>, etc)
+   <literal>SECURITY DEFINER</> functions, use of <command>SET ROLE</>, etc.)
    you may need to take explicit steps to ensure that PL/Perl functions can
    share data via <varname>%_SHARED</varname>.  To do that, make sure that
    functions that should communicate are owned by the same user, and mark
diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml
index e47ad96..0dd2bbc 100644
--- a/doc/src/sgml/pltcl.sgml
+++ b/doc/src/sgml/pltcl.sgml
@@ -228,7 +228,7 @@ $$ LANGUAGE pltcl;
      functions will share the same global variables if and only if they are
      executed by the same SQL role.  In an application wherein a single
      session executes code under multiple SQL roles (via <literal>SECURITY
-     DEFINER</> functions, use of <command>SET ROLE</>, etc) you may need to
+     DEFINER</> functions, use of <command>SET ROLE</>, etc.) you may need to
      take explicit steps to ensure that PL/Tcl functions can share data.  To
      do that, make sure that functions that should communicate are owned by
      the same user, and mark them <literal>SECURITY DEFINER</>.  You must of
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index e519ff9..0c75034 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -140,7 +140,7 @@
     <firstterm>bind</> step, which creates a portal given a prepared
     statement and values for any needed parameters; and an
     <firstterm>execute</> step that runs a portal's query.  In the case of
-    a query that returns rows (<command>SELECT</>, <command>SHOW</>, etc),
+    a query that returns rows (<command>SELECT</>, <command>SHOW</>, etc.),
     the execute step can be told to fetch only
     a limited number of rows, so that multiple execute steps might be needed
     to complete the operation.
@@ -519,7 +519,7 @@
       <listitem>
        <para>
         Indicates that rows are about to be returned in response to
-        a <command>SELECT</command>, <command>FETCH</command>, etc query.
+        a <command>SELECT</command>, <command>FETCH</command>, etc. query.
         The contents of this message describe the column layout of the rows.
         This will be followed by a DataRow message for each row being returned
         to the frontend.
@@ -532,7 +532,7 @@
       <listitem>
        <para>
         One of the set of rows returned by
-        a <command>SELECT</command>, <command>FETCH</command>, etc query.
+        a <command>SELECT</command>, <command>FETCH</command>, etc. query.
        </para>
       </listitem>
      </varlistentry>
@@ -1410,7 +1410,7 @@ The commands accepted in walsender mode are:
       </term>
       <listitem>
       <para>
-       Filename of the timeline history file, e.g <filename>00000002.history</>.
+       Filename of the timeline history file, e.g. <filename>00000002.history</>.
       </para>
       </listitem>
       </varlistentry>
@@ -2101,7 +2101,7 @@ This section describes the base data types used in messages.
                 order (most significant byte first).
                 If <replaceable>i</replaceable> is specified it
                 is the exact value that will appear, otherwise the value
-                is variable.  Eg. Int16, Int32(42).
+                is variable.  E.g. Int16, Int32(42).
 </para>
 </listitem>
 </varlistentry>
@@ -2116,7 +2116,7 @@ This section describes the base data types used in messages.
                 <replaceable>n</replaceable>-bit integers, each in network
                 byte order.  The array length <replaceable>k</replaceable>
                 is always determined by an earlier field in the message.
-                Eg. Int16[M].
+                E.g. Int16[M].
 </para>
 </listitem>
 </varlistentry>
@@ -2131,7 +2131,7 @@ This section describes the base data types used in messages.
                 specific length limitation on strings.
                 If <replaceable>s</replaceable> is specified it is the exact
                 value that will appear, otherwise the value is variable.
-                Eg. String, String("user").
+                E.g. String, String("user").
 </para>
 
 <note>
@@ -2156,7 +2156,7 @@ characters that don't fit into your fixed-size buffer.
                 width <replaceable>n</replaceable> is not a constant, it is
                 always determinable from an earlier field in the message.
                 If <replaceable>c</replaceable> is specified it is the exact
-                value.  Eg. Byte2, Byte1('\n').
+                value.  E.g. Byte2, Byte1('\n').
 </para>
 </listitem>
 </varlistentry>
@@ -3215,7 +3215,7 @@ CopyInResponse (B)
 <para>
                 0 indicates the overall <command>COPY</command> format is textual (rows
                 separated by newlines, columns separated by separator
-                characters, etc).
+                characters, etc.).
                 1 indicates the overall copy format is binary (similar
                 to DataRow format).
                 See <xref linkend="sql-copy">
@@ -3290,7 +3290,7 @@ CopyOutResponse (B)
 <para>
                 0 indicates the overall <command>COPY</command> format
                 is textual (rows separated by newlines, columns
-                separated by separator characters, etc). 1 indicates
+                separated by separator characters, etc.). 1 indicates
                 the overall copy format is binary (similar to DataRow
                 format). See <xref linkend="sql-copy"> for more information.
 </para>
@@ -3363,7 +3363,7 @@ CopyBothResponse (B)
 <para>
                 0 indicates the overall <command>COPY</command> format
                 is textual (rows separated by newlines, columns
-                separated by separator characters, etc). 1 indicates
+                separated by separator characters, etc.). 1 indicates
                 the overall copy format is binary (similar to DataRow
                 format). See <xref linkend="sql-copy"> for more information.
 </para>
diff --git a/doc/src/sgml/ref/values.sgml b/doc/src/sgml/ref/values.sgml
index 0fb3cd7..57ac1d4 100644
--- a/doc/src/sgml/ref/values.sgml
+++ b/doc/src/sgml/ref/values.sgml
@@ -200,7 +200,7 @@ UPDATE employees SET salary = salary * v.increase
    <command>SELECT</>.  It is not required that the <literal>AS</> clause
    specify names for all the columns, but it's good practice to do so.
    (The default column names for <command>VALUES</> are <literal>column1</>,
-   <literal>column2</>, etc in <productname>PostgreSQL</productname>, but
+   <literal>column2</>, etc. in <productname>PostgreSQL</productname>, but
    these names might be different in other database systems.)
   </para>
 
diff --git a/doc/src/sgml/release-7.4.sgml b/doc/src/sgml/release-7.4.sgml
index 5a4c52d..6ebd5e0 100644
--- a/doc/src/sgml/release-7.4.sgml
+++ b/doc/src/sgml/release-7.4.sgml
@@ -1094,7 +1094,7 @@
       subexpression hasn't got a match.  An example is
       <literal>substring('foo' from 'foo(bar)?')</>.
       This should return NULL, since <literal>(bar)</> isn't matched, but
-      it was mistakenly returning the whole-pattern match instead (ie,
+      it was mistakenly returning the whole-pattern match instead (i.e.,
       <literal>foo</>).
      </para>
     </listitem>
@@ -1207,7 +1207,7 @@
     <listitem>
      <para>
       Prevent functions in indexes from executing with the privileges of
-      the user running <command>VACUUM</>, <command>ANALYZE</>, etc (Tom)
+      the user running <command>VACUUM</>, <command>ANALYZE</>, etc. (Tom)
      </para>
 
      <para>
@@ -2159,7 +2159,7 @@ misuse</para></listitem>
 <listitem><para>Change <filename>contrib/tsearch2</> to avoid unsafe use of
 <type>INTERNAL</> function results</para></listitem>
 <listitem><para>Repair ancient race condition that allowed a transaction to be
-seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner
+seen as committed for some purposes (e.g. SELECT FOR UPDATE) slightly sooner
 than for other purposes</para>
 <para>This is an extremely serious bug since it could lead to apparent
 data inconsistencies being briefly visible to applications.</para></listitem>
diff --git a/doc/src/sgml/release-8.0.sgml b/doc/src/sgml/release-8.0.sgml
index 299c34e..e6ffda9 100644
--- a/doc/src/sgml/release-8.0.sgml
+++ b/doc/src/sgml/release-8.0.sgml
@@ -1412,7 +1412,7 @@
       subexpression hasn't got a match.  An example is
       <literal>substring('foo' from 'foo(bar)?')</>.
       This should return NULL, since <literal>(bar)</> isn't matched, but
-      it was mistakenly returning the whole-pattern match instead (ie,
+      it was mistakenly returning the whole-pattern match instead (i.e.,
       <literal>foo</>).
      </para>
     </listitem>
@@ -1606,7 +1606,7 @@
     <listitem>
      <para>
       Prevent functions in indexes from executing with the privileges of
-      the user running <command>VACUUM</>, <command>ANALYZE</>, etc (Tom)
+      the user running <command>VACUUM</>, <command>ANALYZE</>, etc. (Tom)
      </para>
 
      <para>
@@ -2799,7 +2799,7 @@ misuse</para></listitem>
 <listitem><para>Guard against incorrect second parameter to
 <function>record_out</></para></listitem>
 <listitem><para>Repair ancient race condition that allowed a transaction to be
-seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner
+seen as committed for some purposes (e.g. SELECT FOR UPDATE) slightly sooner
 than for other purposes</para>
 <para>This is an extremely serious bug since it could lead to apparent
 data inconsistencies being briefly visible to applications.</para></listitem>
diff --git a/doc/src/sgml/release-8.1.sgml b/doc/src/sgml/release-8.1.sgml
index 0cb5587..495d9c2 100644
--- a/doc/src/sgml/release-8.1.sgml
+++ b/doc/src/sgml/release-8.1.sgml
@@ -1851,7 +1851,7 @@
       subexpression hasn't got a match.  An example is
       <literal>substring('foo' from 'foo(bar)?')</>.
       This should return NULL, since <literal>(bar)</> isn't matched, but
-      it was mistakenly returning the whole-pattern match instead (ie,
+      it was mistakenly returning the whole-pattern match instead (i.e.,
       <literal>foo</>).
      </para>
     </listitem>
@@ -2058,7 +2058,7 @@
     <listitem>
      <para>
       Prevent functions in indexes from executing with the privileges of
-      the user running <command>VACUUM</>, <command>ANALYZE</>, etc (Tom)
+      the user running <command>VACUUM</>, <command>ANALYZE</>, etc. (Tom)
      </para>
 
      <para>
diff --git a/doc/src/sgml/release-8.2.sgml b/doc/src/sgml/release-8.2.sgml
index 7f6a74b..90bd424 100644
--- a/doc/src/sgml/release-8.2.sgml
+++ b/doc/src/sgml/release-8.2.sgml
@@ -3233,7 +3233,7 @@
       subexpression hasn't got a match.  An example is
       <literal>substring('foo' from 'foo(bar)?')</>.
       This should return NULL, since <literal>(bar)</> isn't matched, but
-      it was mistakenly returning the whole-pattern match instead (ie,
+      it was mistakenly returning the whole-pattern match instead (i.e.,
       <literal>foo</>).
      </para>
     </listitem>
@@ -3600,7 +3600,7 @@
     <listitem>
      <para>
       Prevent functions in indexes from executing with the privileges of
-      the user running <command>VACUUM</>, <command>ANALYZE</>, etc (Tom)
+      the user running <command>VACUUM</>, <command>ANALYZE</>, etc. (Tom)
      </para>
 
      <para>
diff --git a/doc/src/sgml/release-8.3.sgml b/doc/src/sgml/release-8.3.sgml
index 3ce96f1..c7b8909 100644
--- a/doc/src/sgml/release-8.3.sgml
+++ b/doc/src/sgml/release-8.3.sgml
@@ -5535,7 +5535,7 @@
       subexpression hasn't got a match.  An example is
       <literal>substring('foo' from 'foo(bar)?')</>.
       This should return NULL, since <literal>(bar)</> isn't matched, but
-      it was mistakenly returning the whole-pattern match instead (ie,
+      it was mistakenly returning the whole-pattern match instead (i.e.,
       <literal>foo</>).
      </para>
     </listitem>
@@ -8350,7 +8350,7 @@ current_date &lt; 2017-11-17
        Provide <function>strlcpy()</function> and
        <function>strlcat()</function> on all platforms, and replace
        error-prone uses of <function>strncpy()</function>,
-       <function>strncat()</function>, etc (Peter)
+       <function>strncat()</function>, etc. (Peter)
       </para>
      </listitem>
 
diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml
index 0baa735..60e5539 100644
--- a/doc/src/sgml/release-8.4.sgml
+++ b/doc/src/sgml/release-8.4.sgml
@@ -1259,7 +1259,7 @@
 
     <listitem>
      <para>
-      Avoid possible failure when performing transaction control commands (e.g
+      Avoid possible failure when performing transaction control commands (e.g.
       <command>ROLLBACK</>) in prepared queries (Tom Lane)
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index 0c77d24..a0f8e9c 100644
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -1465,7 +1465,7 @@
 
     <listitem>
      <para>
-      Avoid possible failure when performing transaction control commands (e.g
+      Avoid possible failure when performing transaction control commands (e.g.
       ROLLBACK) in prepared queries (Tom Lane)
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 4f86b64..3030ee7 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -1653,7 +1653,7 @@
 
     <listitem>
      <para>
-      Avoid possible failure when performing transaction control commands (e.g
+      Avoid possible failure when performing transaction control commands (e.g.
       <command>ROLLBACK</>) in prepared queries (Tom Lane)
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index 911f52a..1dd2f9f 100644
--- a/doc/src/sgml/release-9.2.sgml
+++ b/doc/src/sgml/release-9.2.sgml
@@ -1974,7 +1974,7 @@
 
     <listitem>
      <para>
-      Avoid possible failure when performing transaction control commands (e.g
+      Avoid possible failure when performing transaction control commands (e.g.
       <command>ROLLBACK</>) in prepared queries (Tom Lane)
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 26abce1..a05cfd4 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -324,7 +324,7 @@
     <listitem>
      <para>
       Remove native support for <application>Kerberos</> authentication
-      (<option>--with-krb5</>, etc)
+      (<option>--with-krb5</>, etc.)
       (Magnus Hagander)
      </para>
 
diff --git a/doc/src/sgml/release-old.sgml b/doc/src/sgml/release-old.sgml
index ec8e43f..bfc58da 100644
--- a/doc/src/sgml/release-old.sgml
+++ b/doc/src/sgml/release-old.sgml
@@ -39,7 +39,7 @@
     <listitem>
      <para>
       Prevent functions in indexes from executing with the privileges of
-      the user running <command>VACUUM</>, <command>ANALYZE</>, etc (Tom)
+      the user running <command>VACUUM</>, <command>ANALYZE</>, etc. (Tom)
      </para>
 
      <para>
@@ -782,7 +782,7 @@ UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
 <listitem><para>Change encoding function signature to prevent
 misuse</para></listitem>
 <listitem><para>Repair ancient race condition that allowed a transaction to be
-seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner
+seen as committed for some purposes (e.g. SELECT FOR UPDATE) slightly sooner
 than for other purposes</para>
 <para>This is an extremely serious bug since it could lead to apparent
 data inconsistencies being briefly visible to applications.</para></listitem>
@@ -2010,7 +2010,7 @@ operations on bytea columns (Joe)</para></listitem>
 
 <itemizedlist>
 <listitem><para>Repair ancient race condition that allowed a transaction to be
-seen as committed for some purposes (eg SELECT FOR UPDATE) slightly sooner
+seen as committed for some purposes (e.g. SELECT FOR UPDATE) slightly sooner
 than for other purposes</para>
 <para>This is an extremely serious bug since it could lead to apparent
 data inconsistencies being briefly visible to applications.</para></listitem>
@@ -6387,10 +6387,10 @@ Incompatible changes:
    (due to system catalog changes and indexing structure changes).
  * double-quote (") is deprecated as a quoting character for string literals;
    you need to convert them to single quotes ('). <!-- " -->
- * name of aggregates (eg. int4sum) are renamed in accordance with the
-   SQL standard (eg. sum).
+ * name of aggregates (e.g. int4sum) are renamed in accordance with the
+   SQL standard (e.g. sum).
  * CHANGE ACL syntax is replaced by GRANT/REVOKE syntax.
- * float literals (eg. 3.14) are now of type float4 (instead of float8 in
+ * float literals (e.g. 3.14) are now of type float4 (instead of float8 in
    previous releases); you might have to do typecasting if you depend on it
    being of type float8.  If you neglect to do the typecasting and you assign
    a float literal to a field of type float8, you might get incorrect values
@@ -6449,7 +6449,7 @@ Bug fixes:
 
 Other changes and enhancements:
  * addition of an EXPLAIN statement used for explaining the query execution
-   plan (eg. "EXPLAIN SELECT * FROM EMP" prints out the execution plan for
+   plan (e.g. "EXPLAIN SELECT * FROM EMP" prints out the execution plan for
    the query).
  * WARN and NOTICE messages no longer have timestamps on them. To turn on
    timestamps of error messages, uncomment the line in
diff --git a/doc/src/sgml/sources.sgml b/doc/src/sgml/sources.sgml
index aa20807..a66ad72 100644
--- a/doc/src/sgml/sources.sgml
+++ b/doc/src/sgml/sources.sgml
@@ -13,9 +13,9 @@
    </para>
 
    <para>
-    Layout rules (brace positioning, etc) follow BSD conventions.  In
+    Layout rules (brace positioning, etc.) follow BSD conventions.  In
     particular, curly braces for the controlled blocks of <literal>if</>,
-    <literal>while</>, <literal>switch</>, etc go on their own lines.
+    <literal>while</>, <literal>switch</>, etc. go on their own lines.
    </para>
 
    <para>
diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml
index 434a894..f377d5c 100644
--- a/doc/src/sgml/syntax.sgml
+++ b/doc/src/sgml/syntax.sgml
@@ -1065,7 +1065,7 @@ SELECT (5 !) - 6;
       <row>
        <entry><token>IS</token></entry>
        <entry></entry>
-       <entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS NULL</>, etc</entry>
+       <entry><literal>IS TRUE</>, <literal>IS FALSE</>, <literal>IS NULL</>, etc.</entry>
       </row>
 
       <row>
diff --git a/doc/src/sgml/tsearch2.sgml b/doc/src/sgml/tsearch2.sgml
index 192eccd..f0a7850 100644
--- a/doc/src/sgml/tsearch2.sgml
+++ b/doc/src/sgml/tsearch2.sgml
@@ -162,7 +162,7 @@
      Load the dump data.  There will be quite a few errors reported
      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
+     restore the dump in a single transaction (e.g., you cannot use
      <application>pg_restore</>'s <option>-1</> switch).
     </para>
    </step>
diff --git a/doc/src/sgml/xml2.sgml b/doc/src/sgml/xml2.sgml
index c4b85bf..1c9305c 100644
--- a/doc/src/sgml/xml2.sgml
+++ b/doc/src/sgml/xml2.sgml
@@ -328,7 +328,7 @@ AS t(article_id integer, author text, page_count integer, title text);
    just <literal>SELECT *</> &mdash; it can reference the output
    columns by name or join them to other tables. The function produces a
    virtual table with which you can perform any operation you wish (e.g.
-   aggregation, joining, sorting etc). So we could also have:
+   aggregation, joining, sorting etc.). So we could also have:
 <programlisting>
 SELECT t.title, p.fullname, p.email
 FROM xpath_table('article_id', 'article_xml', 'articles',
-- 
2.1.0

From f3d5c47a1e64596ac1b67bd0bf4819141a74acf1 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <[email-masked]>
Date: Mon, 25 Aug 2014 20:25:01 +0300
Subject: [PATCH 3/3] doc: Tweaks for "newly-", "recently-", "exact same"

---
 doc/src/sgml/config.sgml            | 2 +-
 doc/src/sgml/high-availability.sgml | 4 ++--
 doc/src/sgml/mvcc.sgml              | 2 +-
 doc/src/sgml/pltcl.sgml             | 2 +-
 doc/src/sgml/ref/psql-ref.sgml      | 2 +-
 doc/src/sgml/release-8.0.sgml       | 6 +++---
 doc/src/sgml/release-8.1.sgml       | 6 +++---
 doc/src/sgml/release-8.2.sgml       | 2 +-
 doc/src/sgml/release-8.3.sgml       | 6 +++---
 doc/src/sgml/release-8.4.sgml       | 4 ++--
 doc/src/sgml/release-9.0.sgml       | 4 ++--
 doc/src/sgml/release-9.1.sgml       | 4 ++--
 12 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 72f2a2a..a83e1e7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -6432,7 +6432,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
        <para>
         This controls whether <command>CREATE TABLE</command> and
         <command>CREATE TABLE AS</command> include an OID column in
-        newly-created tables, if neither <literal>WITH OIDS</literal>
+        newly created tables, if neither <literal>WITH OIDS</literal>
         nor <literal>WITHOUT OIDS</literal> is specified. It also
         determines whether OIDs will be included in tables created by
         <command>SELECT INTO</command>. The parameter is <literal>off</>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index d249959..20c9ccb 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1809,7 +1809,7 @@ if (!triggered)
     linkend="guc-max-standby-streaming-delay">, that define the maximum
     allowed delay in WAL application.  Conflicting queries will be canceled
     once it has taken longer than the relevant delay setting to apply any
-    newly-received WAL data.  There are two parameters so that different delay
+    newly received WAL data.  There are two parameters so that different delay
     values can be specified for the case of reading WAL data from an archive
     (i.e., initial recovery from a base backup or <quote>catching up</> a
     standby server that has fallen far behind) versus reading WAL data via
@@ -1897,7 +1897,7 @@ if (!triggered)
     so that queries are not rapidly canceled by conflicts in WAL archive
     files during disconnected periods.  You should also consider increasing
     <varname>max_standby_streaming_delay</> to avoid rapid cancellations
-    by newly-arrived streaming WAL entries after reconnection.
+    by newly arrived streaming WAL entries after reconnection.
    </para>
 
    <para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index cd55be8..af8d10f 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -139,7 +139,7 @@
       <para>
         A transaction re-executes a query returning a set of rows that satisfy a
         search condition and finds that the set of rows satisfying the condition
-        has changed due to another recently-committed transaction.
+        has changed due to another recently committed transaction.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/pltcl.sgml b/doc/src/sgml/pltcl.sgml
index 0dd2bbc..9839d55 100644
--- a/doc/src/sgml/pltcl.sgml
+++ b/doc/src/sgml/pltcl.sgml
@@ -51,7 +51,7 @@
     Sometimes it is desirable to write Tcl functions that are not restricted
     to safe Tcl.  For example, one might want a Tcl function that sends
     email.  To handle these cases, there is a variant of <application>PL/Tcl</> called <literal>PL/TclU</>
-    (for untrusted Tcl).  This is the exact same language except that a full
+    (for untrusted Tcl).  This is exactly the same language except that a full
     Tcl interpreter is used.  <emphasis>If <application>PL/TclU</> is used, it must be
     installed as an untrusted procedural language</emphasis> so that only
     database superusers can create functions in it.  The writer of a <application>PL/TclU</>
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
index 74d4618..d0f7c0f 100644
--- a/doc/src/sgml/ref/psql-ref.sgml
+++ b/doc/src/sgml/ref/psql-ref.sgml
@@ -1838,7 +1838,7 @@ foo=&gt; <userinput>\lo_import '/home/peter/pictures/photo.xcf' 'a picture of me
 lo_import 152801
 </programlisting>
         The response indicates that the large object received object
-        ID 152801, which can be used to access the newly-created large
+        ID 152801, which can be used to access the newly created large
         object in the future. For the sake of readability, it is
         recommended to always associate a human-readable comment with
         every object. Both OIDs and comments can be viewed with the
diff --git a/doc/src/sgml/release-8.0.sgml b/doc/src/sgml/release-8.0.sgml
index e6ffda9..ed00347 100644
--- a/doc/src/sgml/release-8.0.sgml
+++ b/doc/src/sgml/release-8.0.sgml
@@ -1080,7 +1080,7 @@
 
     <listitem>
      <para>
-      Ensure an error is reported when a newly-defined PL/pgSQL trigger
+      Ensure an error is reported when a newly defined PL/pgSQL trigger
       function is invoked as a normal function (Tom)
      </para>
     </listitem>
@@ -2505,7 +2505,7 @@ many connection requests arrive close together.  This applies
 
 <listitem><para>Fix bug introduced in 8.0 that could allow ReadBuffer
 to return an already-used page as new, potentially causing loss of
-recently-committed data (Tom)</para></listitem>
+recently committed data (Tom)</para></listitem>
 
 <listitem><para>Fix for protocol-level Describe messages issued
 outside a transaction or in a failed transaction (Tom)</para></listitem>
@@ -3555,7 +3555,7 @@ typedefs (Michael)</para></listitem>
        New buffer replacement strategy that improves caching (Jan)
       </para>
       <para>
-       Prior releases used a least-recently-used (LRU) cache to keep
+       Prior releases used a least recently used (LRU) cache to keep
        recently referenced pages in memory. The LRU algorithm
        did not consider the number of times a specific cache entry was
        accessed, so large table scans could force out useful cache pages.
diff --git a/doc/src/sgml/release-8.1.sgml b/doc/src/sgml/release-8.1.sgml
index 495d9c2..6eb6d1c 100644
--- a/doc/src/sgml/release-8.1.sgml
+++ b/doc/src/sgml/release-8.1.sgml
@@ -1451,7 +1451,7 @@
 
     <listitem>
      <para>
-      Ensure an error is reported when a newly-defined PL/pgSQL trigger
+      Ensure an error is reported when a newly defined PL/pgSQL trigger
       function is invoked as a normal function (Tom)
      </para>
     </listitem>
@@ -3164,7 +3164,7 @@ many connection requests arrive close together.  This applies
 
 <listitem><para>Fix bug introduced in 8.0 that could allow ReadBuffer
 to return an already-used page as new, potentially causing loss of
-recently-committed data (Tom)</para></listitem>
+recently committed data (Tom)</para></listitem>
 
 <listitem><para>Fix for protocol-level Describe messages issued
 outside a transaction or in a failed transaction (Tom)</para></listitem>
@@ -3717,7 +3717,7 @@ DISTINCT query</para></listitem>
       <function>currval()</>, and <function>setval()</> were stored as
       simple text strings, meaning that renaming or dropping a
       sequence used in a <literal>DEFAULT</> clause made the clause
-      invalid. This release stores all newly-created sequence function
+      invalid. This release stores all newly created sequence function
       arguments as internal OIDs, allowing them to track sequence
       renaming, and adding dependency information that prevents
       improper sequence removal. It also makes such <literal>DEFAULT</>
diff --git a/doc/src/sgml/release-8.2.sgml b/doc/src/sgml/release-8.2.sgml
index 90bd424..4bf4af5 100644
--- a/doc/src/sgml/release-8.2.sgml
+++ b/doc/src/sgml/release-8.2.sgml
@@ -2722,7 +2722,7 @@
 
     <listitem>
      <para>
-      Ensure an error is reported when a newly-defined PL/pgSQL trigger
+      Ensure an error is reported when a newly defined PL/pgSQL trigger
       function is invoked as a normal function (Tom)
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-8.3.sgml b/doc/src/sgml/release-8.3.sgml
index c7b8909..92f6e52 100644
--- a/doc/src/sgml/release-8.3.sgml
+++ b/doc/src/sgml/release-8.3.sgml
@@ -1165,7 +1165,7 @@
 
     <listitem>
      <para>
-      Fix recently-introduced memory leak in processing of
+      Fix recently introduced memory leak in processing of
       <type>inet</>/<type>cidr</> values (Heikki Linnakangas)
      </para>
 
@@ -4700,7 +4700,7 @@
 
     <listitem>
      <para>
-      Ensure an error is reported when a newly-defined PL/pgSQL trigger
+      Ensure an error is reported when a newly defined PL/pgSQL trigger
       function is invoked as a normal function (Tom)
      </para>
     </listitem>
@@ -5410,7 +5410,7 @@
      <para>
       In the worst case this could result in deleting a newly created table
       in a new database that happened to get the same OID as the
-      recently-dropped one; but of course that is an extremely
+      recently dropped one; but of course that is an extremely
       low-probability scenario.
      </para>
     </listitem>
diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml
index 60e5539..7f6a176 100644
--- a/doc/src/sgml/release-8.4.sgml
+++ b/doc/src/sgml/release-8.4.sgml
@@ -2862,7 +2862,7 @@
 
     <listitem>
      <para>
-      Fix recently-introduced memory leak in processing of
+      Fix recently introduced memory leak in processing of
       <type>inet</>/<type>cidr</> values (Heikki Linnakangas)
      </para>
 
@@ -6275,7 +6275,7 @@ WITH w AS (SELECT * FROM foo) SELECT * FROM w, bar ... FOR UPDATE
 
     <listitem>
      <para>
-      Fix <application>ecpg</> to not treat recently-added keywords as
+      Fix <application>ecpg</> to not treat recently added keywords as
       reserved words (Tom)
      </para>
 
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index a0f8e9c..cdccd9f 100644
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -3342,7 +3342,7 @@
     <listitem>
      <para>
       Fix <command>CLUSTER</>/<command>VACUUM FULL</> handling of toast
-      values owned by recently-updated rows (Tom Lane)
+      values owned by recently updated rows (Tom Lane)
      </para>
 
      <para>
@@ -3498,7 +3498,7 @@
 
     <listitem>
      <para>
-      Fix recently-introduced memory leak in processing of
+      Fix recently introduced memory leak in processing of
       <type>inet</>/<type>cidr</> values (Heikki Linnakangas)
      </para>
 
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 3030ee7..d4fa329 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -4101,7 +4101,7 @@
     <listitem>
      <para>
       Fix <command>CLUSTER</>/<command>VACUUM FULL</> handling of toast
-      values owned by recently-updated rows (Tom Lane)
+      values owned by recently updated rows (Tom Lane)
      </para>
 
      <para>
@@ -4264,7 +4264,7 @@
 
     <listitem>
      <para>
-      Fix recently-introduced memory leak in processing of
+      Fix recently introduced memory leak in processing of
       <type>inet</>/<type>cidr</> values (Heikki Linnakangas)
      </para>
 
-- 
2.1.0

---

From: Kevin Grittner <[email-masked]>
Date: Mon, 25 Aug 2014 12:13:51 -0700

> Attached is a patch with hand-picked fixes that are clearly an

For the initial patch, I agree with all except the first change of
"others'" to "other's" -- the start of the sentence uses "All", so
there is clearly more than one "other", so the the apostrophe
belongs after the "s".  The rest of the 0001- patch all look like
improvements to me.

I think most or all of the places that the 0002- patch (i.e. and
e.g.) need a change to look right, but I'm not sure this goes far
enough.  In style guides I've had to use these generally should
follow punctuation (left parenthesis, colon, semi-colon, comma, or
em dash), and be separated from any following text by punctuation
-- usually a comma.

In patch 0003- I agree that the change to "exactly the same" reads
better.  I'm torn on changing the hyphens to spaces.  I probably
wouldn't change them, but I wouldn't squawk if others preferred to
do so.

---

From: Marti Raudsepp <[email-masked]>
Date: Tue, 26 Aug 2014 00:05:09 +0300

On Mon, Aug 25, 2014 at 10:13 PM, Kevin Grittner <[email-masked]> wrote:
> belongs after the "s".

Not arguing against this, but all the grammar advice I've read
suggests that "each others' " is always wrong. For example
http://jakubmarian.com/each-others-vs-each-others-in-english/

To illustrate this better, supposedly the "other" can be swapped out
for "statement":

All the statements are executed with the same snapshot, so they cannot
see each statements' effects / each statement's effects

What do you think?

> em dash), and be separated from any following text by punctuation

This matches my research too. I wrote two rules to add commas where no
punctation was being used:

<Typo word="Add comma after i.e. & e.g."
      find="\b([Ii]\.e|[Ee]\.g)\.? ?(\s|$)"
      replace="$1.,$2" />
<Typo word="Add comma before i.e. & e.g."
      find="([a-z])(\s+([Ii]\.e|[Ee]\.g))\b"
      replace="$1,$2" />

Attached is the updated 0002 patch. I skimmed over all the differences
and they looked good to me, but with 124 more lines touched, it's
possible that I missed something.

> wouldn't change them

Agreed. I'll move the "exactly the same" hunk to patch 0001 once we
settle the "each other" question.

Thanks,
Marti

---

From: Kevin Grittner <[email-masked]>
Date: Mon, 25 Aug 2014 14:59:58 -0700

Marti Raudsepp <[email-masked]> wrote:
> Kevin Grittner <[email-masked]> wrote:

> http://jakubmarian.com/each-others-vs-each-others-in-english/

Hmm.  I checked with the Chicago Manual of Style, which is my
preferred source, and it agrees that "each others'" is always
wrong.  More than that, it says that traditionalists use "each
other" when exactly two are involved and "one another" when more
than two are involved.  So to be totally proper, that instance of
"each others'" should be "one another's".  ("One anothers'" is also
always wrong.)

> possible that I missed something.

I'll need a little more time to digest all of those in detail, too. 
It sounds like we agree.  Where a couple occurrences of "etc" are 
being to abbreviate a code example we might have a special case, but 
otherwise these are likely to all be the way I'm used to seeing 
them.

> Agreed. I'll move the "exactly the same" hunk to patch 0001 once
> we settle the "each other" question.

Sounds like a good idea.  Each patch file is then dealing with a
distinct set of issues.

---

From: Marti Raudsepp <[email-masked]>
Date: Tue, 26 Aug 2014 21:54:29 +0300

On Tue, Aug 26, 2014 at 12:59 AM, Kevin Grittner <[email-masked]> wrote:
> More than that, it says that traditionalists use "each

Ok, changed to "one another's". (I will say it sounds a bit odd to me,
but I suppose it is more correct).

All updated patches attached, per our previous discussion. Patches 1-2
are ready, 3 can be discarded unless someone else chimes in.

Do you think it's worth doing a run over developer documentation
(README files) and code comments too, or is that a waste of time?

Regards,
Marti

---

From: Kevin Grittner <[email-masked]>
Date: Sat, 30 Aug 2014 09:33:03 -0700

Marti Raudsepp <[email-masked]> wrote:

> All updated patches attached, per our previous discussion.
> Patches 1-2 are ready, 3 can be discarded unless someone else
> chimes in.

Patch 1 pushed, with each fix back-patched as far as the error
exists in supported releases.  I held off on patch 2 -- partly
because I spotted at least one case where things weren't quite
right, partly because there's so much I haven't had time to go over
it in sufficient detail, and partly because commas are omitted so
consistently where most style guides want them that I thought
someone might want to argue that this was an intentional style
choice and should be preserved.  I'm also not sure that it should
be back-patched as the outright errors were -- it does seem like
more of a style issue than most of the things in patch 1 were,
which included clear misspellings, accidentally repeated words, and
incorrect choices of indefinite articles.

The remaining error I mentioned above was an occurrence of a
parenthetical remark which started with "e.g.," and ended with
", etc.").  The Chicago Manual of Style says that you can use one
or the other, but using both is redundant and should be avoided.

> (README files) and code comments too, or is that a waste of time?

Some README files could use a lot of attention; I'm just not sure
that fixing a few misspelling, repeated words, or grammar errors
makes enough of a dent in what is needed to be worth it.

---

From: Tom Lane <[email-masked]>
Date: Sat, 30 Aug 2014 13:43:26 -0400

Kevin Grittner <[email-masked]> writes:
> choice and should be preserved.

I would argue against applying patch 2 at all.  I think it's what
John McIntyre (http://www.baltimoresun.com/news/language-blog/)
would call peeverism.  If there are any places where the extra
commas/periods actually add anything to clarity, then sure, change
those places --- but doing it only because some style guide tells
you to is not the way to approach the issue.  We're writing English
not C code here, and so there is no single standard of correctness.

			regards, tom lane

---

From: David G Johnston <[email-masked]>
Date: Sat, 30 Aug 2014 14:44:03 -0700 (PDT)

Tom Lane-2 wrote
> Kevin Grittner &lt;

> kgrittn@

> &gt; writes:

Writing C code, aside from purely syntactic concerns, does not abide by a
single standard of style correctness either yet this project does have a
style guide that is to be adhered to.  I do not think it to be a bad thing
to accept a style guide as reference for the documentation as well.

My main objections are:

1) we are simply treating symptoms
2) we are introducing a decent amount of not-meaning-enhancing change

But if one is going to adopt a lassiez-faire attitude then whether or not
patch 2 (and 3) is applied should make little difference.  

And given the surgical nature of the update in question the commit history
of the documentation is practically unaffected.

As a matter of internal consistency, and also for adherence to "best
practices", I'd vote to apply all three patches once fully reviewed - though
by the same logic above if we miss a few items the overall impact on the
qualify of the documentation will still be positive and the incorrect
locations will likely still be understandable.

I don't expect writers to be able to keep straight all of the style rules
that we'd like to try and adhere to but having good existing documentation
will make it more likely for new content to conform.  The goal would be to
let them focus on writing but then have some kind of editing process - which
is what is going on now - to aid in polishing the final publication.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/PATCH-Various-documentation-typo-grammar-fixes-tp5816078p5817040.html
Sent from the PostgreSQL - docs mailing list archive at Nabble.com.

---

From: Marti Raudsepp <[email-masked]>
Date: Wed, 3 Sep 2014 00:09:08 +0300

On Sat, Aug 30, 2014 at 8:43 PM, Tom Lane <[email-masked]> wrote:
> I would argue against applying patch 2 at all.

I don't feel strongly about this, I originally didn't plan to submit
this patch at all. But I don't agree with:

> doing it only because some style guide tells

There isn't a "single standard", but there are many style guides about
English and pretty much all of them agree on the usage of periods in
"e.g.", "i.e.", "etc." and "et al."

With regards to commas following e.g. and i.e., this article surveyed
6 different English style guides and just 1 recommended not using the
comma: http://www.quickanddirtytips.com/education/grammar/ie-versus-eg?page=2

Regards,
Marti

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 2 Sep 2014 17:30:37 -0400

> wouldn't change them, but I wouldn't squawk if others preferred to

Apparently adverb hyphenation discussion plagues the web.  One
reasonably-serious page I found in a very quick search is
http://www.dailywritingtips.com/adverbs-and-hyphens/
which cites the Chicago Manual of Style, among others.

There are lots of places in our docs that use hyphens after the "-ly"
suffix, so I think patch 3 is either too short because it should change
more of them, or too long because we should leave this alone.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

---

From: Kevin Grittner <[email-masked]>
Date: Tue, 2 Sep 2014 14:46:40 -0700

Alvaro Herrera <[email-masked]> wrote:

> One reasonably-serious page

... and with that, I guess you've expressed a reasonably clear 
preference.  ;-)

---

From: Kevin Grittner <[email-masked]>
Date: Wed, 3 Sep 2014 06:19:24 -0700

> "e.g.", "i.e.", "etc." and "et al."

To me, omitting the dots in any of those looks like a misspelling.
I think we should fix those.

Also, it seems odd to so strictly enforce formatting rules in C
code (where it makes no semantic difference) but blow off style
issues, and even correctness of English usage, in the
documentation.

> comma: http://www.quickanddirtytips.com/education/grammar/ie-versus-eg?page=2

Commas after "i.e." and "e.g." are less clearly a correctness issue 
and getting more into style questions, so I wouldn't feel too bad 
about letting those go where it doesn't cause confusion or too much 
of a "double take" on reading.  Note that the cited page summarizes 
the positions of these documents on the topic with phrases like "is 
usually used", "preferable/optional", "makes good sense", and 
"should be".  Only "The Columbia Guide to Standard American 
English" actually said it was "required".

Starting a parenthetical clause with "e.g." and ending it with
", etc." also looks wrong to me.  My inclination is to pick one;
otherwise I find it distracting or confusing and tend to go back
over it one or two extra times to make sure I'm understanding.

There's at least one place I spotted "e.g." where it seemed to me
that the "example" was really a restatement in other terms, so it
seemed like it should have been "i.e." -- I would be inclined to
scan for more of those and present that as a separate patch, since
it's less mechanical than the others.