|
1 | 1 | <!--
|
2 |
| -$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.40 2004/11/15 06:32:14 neilc Exp $ |
| 2 | +$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.41 2004/12/17 04:50:32 tgl Exp $ |
3 | 3 | -->
|
4 | 4 |
|
5 | 5 | <chapter id="tutorial-sql">
|
@@ -154,7 +154,7 @@ CREATE TABLE weather (
|
154 | 154 | </para>
|
155 | 155 |
|
156 | 156 | <para>
|
157 |
| - <productname>PostgreSQL</productname> supports the usual |
| 157 | + <productname>PostgreSQL</productname> supports the standard |
158 | 158 | <acronym>SQL</acronym> types <type>int</type>,
|
159 | 159 | <type>smallint</type>, <type>real</type>, <type>double
|
160 | 160 | precision</type>, <type>char(<replaceable>N</>)</type>,
|
@@ -297,8 +297,8 @@ SELECT * FROM weather;
|
297 | 297 | <footnote>
|
298 | 298 | <para>
|
299 | 299 | While <literal>SELECT *</literal> is useful for off-the-cuff
|
300 |
| - queries, it is considered bad style in production code for |
301 |
| - maintenance reasons: adding a column to the table changes the results. |
| 300 | + queries, it is widely considered bad style in production code, |
| 301 | + since adding a column to the table would change the results. |
302 | 302 | </para>
|
303 | 303 | </footnote>
|
304 | 304 | The output should be:
|
@@ -400,9 +400,9 @@ SELECT DISTINCT city
|
400 | 400 | the cities table, and select the pairs of rows where these values match.
|
401 | 401 | <note>
|
402 | 402 | <para>
|
403 |
| - This is only a conceptual model. The actual join may |
404 |
| - be performed in a more efficient manner, but this is invisible |
405 |
| - to the user. |
| 403 | + This is only a conceptual model. The join is usually performed |
| 404 | + in a more efficient manner than actually comparing each possible |
| 405 | + pair of rows, but this is invisible to the user. |
406 | 406 | </para>
|
407 | 407 | </note>
|
408 | 408 | This would be accomplished by the following query:
|
@@ -727,15 +727,15 @@ SELECT city, max(temp_lo)
|
727 | 727 | aggregates are computed. Thus, the
|
728 | 728 | <literal>WHERE</literal> clause must not contain aggregate functions;
|
729 | 729 | it makes no sense to try to use an aggregate to determine which rows
|
730 |
| - will be inputs to the aggregates. On the other hand, |
| 730 | + will be inputs to the aggregates. On the other hand, the |
731 | 731 | <literal>HAVING</literal> clause always contains aggregate functions.
|
732 | 732 | (Strictly speaking, you are allowed to write a <literal>HAVING</literal>
|
733 |
| - clause that doesn't use aggregates, but it's wasteful: The same condition |
| 733 | + clause that doesn't use aggregates, but it's wasteful. The same condition |
734 | 734 | could be used more efficiently at the <literal>WHERE</literal> stage.)
|
735 | 735 | </para>
|
736 | 736 |
|
737 | 737 | <para>
|
738 |
| - Observe that we can apply the city name restriction in |
| 738 | + In the previous example, we can apply the city name restriction in |
739 | 739 | <literal>WHERE</literal>, since it needs no aggregate. This is
|
740 | 740 | more efficient than adding the restriction to <literal>HAVING</literal>,
|
741 | 741 | because we avoid doing the grouping and aggregate calculations
|
@@ -788,10 +788,10 @@ SELECT * FROM weather;
|
788 | 788 | </indexterm>
|
789 | 789 |
|
790 | 790 | <para>
|
| 791 | + Rows can be removed from a table using the <command>DELETE</command> |
| 792 | + command. |
791 | 793 | Suppose you are no longer interested in the weather of Hayward.
|
792 |
| - Then you can do the following to delete those rows from the table. |
793 |
| - Deletions are performed using the <command>DELETE</command> |
794 |
| - command: |
| 794 | + Then you can do the following to delete those rows from the table: |
795 | 795 | <programlisting>
|
796 | 796 | DELETE FROM weather WHERE city = 'Hayward';
|
797 | 797 | </programlisting>
|
|
0 commit comments