|
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 theusual |
| 157 | + <productname>PostgreSQL</productname> supports thestandard |
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 tablechanges the results. |
| 300 | + queries, it iswidelyconsidered bad style in production code, |
| 301 | +sinceadding a column to the tablewould 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. Theactualjoinmay |
404 | | -be performedin a more efficient manner, but this is invisible |
405 | | - to the user. |
| 403 | + This is only a conceptual model. The joinis usually performed |
| 404 | + in a more efficient manner than actually comparing each possible |
| 405 | +pair of rows, but this is invisibleto 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> |
|