mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Minor copy-editing in tutorial.

Browse Source
This commit is contained in:
Tom Lane 2004-12-17 04:50:32 +00:00
parent 1ef38f2691
commit 92c001bbaf
3 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/sgml/advanced.sgml
View File

@ -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.

26
doc/src/sgml/query.sgml
View File

@ -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>

4
doc/src/sgml/start.sgml
View File

@ -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.