From 92c001bbaf86ac171fb361e81aa962ae873b52c2 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 17 Dec 2004 04:50:32 +0000
Subject: [PATCH] Minor copy-editing in tutorial.

---
 doc/src/sgml/advanced.sgml |  4 ++--
 doc/src/sgml/query.sgml    | 26 +++++++++++++-------------
 doc/src/sgml/start.sgml    |  4 ++--
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 64ff4616e2..82d9e229b3 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.46 2004/11/15 06:32:13 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/advanced.sgml,v 1.47 2004/12/17 04:50:32 tgl Exp $
 -->
 
  <chapter id="tutorial-advanced">
@@ -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 8240281b3d..33294afd3c 100644
--- a/doc/src/sgml/query.sgml
+++ b/doc/src/sgml/query.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.40 2004/11/15 06:32:14 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.41 2004/12/17 04:50:32 tgl Exp $
 -->
 
  <chapter id="tutorial-sql">
@@ -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 fc53a20a14..c40f76c8ce 100644
--- a/doc/src/sgml/start.sgml
+++ b/doc/src/sgml/start.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.36 2004/06/29 19:57:40 petere Exp $
+$PostgreSQL: pgsql/doc/src/sgml/start.sgml,v 1.37 2004/12/17 04:50:32 tgl Exp $
 -->
 
  <chapter id="tutorial-start">
@@ -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.
-- 
2.40.0