Minor copy-editing in tutorial.

diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 81a387701aba691b212954457b85f8888d74d182..064f955ed008d8d86d6d9f237bf176208a3868f4 100644 (file)
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -196,7 +196,7 @@ UPDATE branches SET balance = balance + 100.00
     and won't be lost even if a crash ensues shortly thereafter.
     For example, if we are recording a cash withdrawal by Bob,
     we do not want any chance that the debit to his account will
-    disappear in a crash just as he walks out the bank door.
+    disappear in a crash just after he walks out the bank door.
     A transactional database guarantees that all the updates made by
     a transaction are logged in permanent storage (i.e., on disk) before
     the transaction is reported complete.

diff --git a/doc/src/sgml/query.sgml b/doc/src/sgml/query.sgml
index 23b1a5356734ddd16308bf89b6e08b6401c641ba..d4eae7eb03962d48f295c21c8c7689a57fad999b 100644 (file)
--- a/doc/src/sgml/query.sgml
+++ b/doc/src/sgml/query.sgml
@@ -154,7 +154,7 @@ CREATE TABLE weather (
    </para>
 
    <para>
-    <productname>PostgreSQL</productname> supports the usual
+    <productname>PostgreSQL</productname> supports the standard
     <acronym>SQL</acronym> types <type>int</type>,
     <type>smallint</type>, <type>real</type>, <type>double
     precision</type>, <type>char(<replaceable>N</>)</type>,
@@ -297,8 +297,8 @@ SELECT * FROM weather;
      <footnote>
       <para>
        While <literal>SELECT *</literal> is useful for off-the-cuff
-       queries, it is considered bad style in production code for
-       maintenance reasons: adding a column to the table changes the results.
+       queries, it is widely considered bad style in production code,
+       since adding a column to the table would change the results.
       </para>
      </footnote>
     The output should be:
@@ -400,9 +400,9 @@ SELECT DISTINCT city
     the cities table, and select the pairs of rows where these values match.
     <note>
      <para>
-      This  is only a conceptual model.  The actual join may
-      be performed in a more efficient manner, but this is invisible
-      to the user.
+      This  is only a conceptual model.  The join is usually performed
+      in a more efficient manner than actually comparing each possible
+      pair of rows, but this is invisible to the user.
      </para>
     </note>
     This would be accomplished by the following query:
@@ -727,15 +727,15 @@ SELECT city, max(temp_lo)
     aggregates are computed.  Thus, the
     <literal>WHERE</literal> clause must not contain aggregate functions;
     it makes no sense to try to use an aggregate to determine which rows
-    will be inputs to the aggregates.  On the other hand,
+    will be inputs to the aggregates.  On the other hand, the
     <literal>HAVING</literal> clause always contains aggregate functions.
     (Strictly speaking, you are allowed to write a <literal>HAVING</literal>
-    clause that doesn't use aggregates, but it's wasteful: The same condition
+    clause that doesn't use aggregates, but it's wasteful. The same condition
     could be used more efficiently at the <literal>WHERE</literal> stage.)
    </para>
 
    <para>
-    Observe that we can apply the city name restriction in
+    In the previous example, we can apply the city name restriction in
     <literal>WHERE</literal>, since it needs no aggregate.  This is
     more efficient than adding the restriction to <literal>HAVING</literal>,
     because we avoid doing the grouping and aggregate calculations
@@ -788,10 +788,10 @@ SELECT * FROM weather;
    </indexterm>
 
    <para>
+    Rows can be removed from a table using the <command>DELETE</command>
+    command.
     Suppose you are no longer interested in the weather of Hayward.
-    Then you can do the following to delete those rows from the table.
-    Deletions are performed using the <command>DELETE</command>
-    command:
+    Then you can do the following to delete those rows from the table:
 <programlisting>
 DELETE FROM weather WHERE city = 'Hayward';
 </programlisting>

diff --git a/doc/src/sgml/start.sgml b/doc/src/sgml/start.sgml
index d8340ad2ac936a2901bf54470a6e5af83590d6db..02674a5e451f475696bbd3c4fb22a5d5e5050bcf 100644 (file)
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -218,7 +218,7 @@ createdb: database creation failed: ERROR:  permission denied to create database
       operating system account.  As it happens, there will always be a
       <productname>PostgreSQL</productname> user account that has the
       same name as the operating system user that started the server,
-      and it also happens that the user always has permission to
+      and it also happens that that user always has permission to
       create databases.  Instead of logging in as that user you can
       also specify the <option>-U</option> option everywhere to select
       a <productname>PostgreSQL</productname> user name to connect as.