1
1
<!--
2
- $PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.41 2004/12/17 04:50:32 tgl Exp $
2
+ $PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.42 2005/01/08 01:44:08 tgl Exp $
3
3
-->
4
4
5
5
<chapter id="tutorial-sql">
@@ -293,14 +293,19 @@ COPY weather FROM '/home/user/weather.txt';
293
293
<programlisting>
294
294
SELECT * FROM weather;
295
295
</programlisting>
296
- (here <literal>*</literal>means <quote>all columns</quote>) .
296
+ Here <literal>*</literal>is a shorthand for <quote>all columns</quote>.
297
297
<footnote>
298
298
<para>
299
299
While <literal>SELECT *</literal> is useful for off-the-cuff
300
300
queries, it is widely considered bad style in production code,
301
301
since adding a column to the table would change the results.
302
302
</para>
303
303
</footnote>
304
+ So the same result would be had with:
305
+ <programlisting>
306
+ SELECT city, temp_lo, temp_hi, prcp, date FROM weather;
307
+ </programlisting>
308
+
304
309
The output should be:
305
310
306
311
<screen>
@@ -314,8 +319,8 @@ SELECT * FROM weather;
314
319
</para>
315
320
316
321
<para>
317
- Youmay specify any arbitrary expressions in the select list. For
318
- example, you can do:
322
+ Youcan write expressions, not just simple column references, in the
323
+ select list. For example, you can do:
319
324
<programlisting>
320
325
SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
321
326
</programlisting>
@@ -333,15 +338,18 @@ SELECT city, (temp_hi+temp_lo)/2 AS temp_avg, date FROM weather;
333
338
</para>
334
339
335
340
<para>
336
- Arbitrary Boolean operators (<literal>AND</literal>,
341
+ A query can be <quote>qualified</> by adding a <literal>WHERE</>
342
+ clause that specifies which rows are wanted. The <literal>WHERE</>
343
+ clause contains a Boolean (truth value) expression, and only rows for
344
+ which the Boolean expression is true are returned. The usual
345
+ Boolean operators (<literal>AND</literal>,
337
346
<literal>OR</literal>, and <literal>NOT</literal>) are allowed in
338
- the qualification of a query . For example, the following
347
+ the qualification. For example, the following
339
348
retrieves the weather of San Francisco on rainy days:
340
349
341
350
<programlisting>
342
351
SELECT * FROM weather
343
- WHERE city = 'San Francisco'
344
- AND prcp > 0.0;
352
+ WHERE city = 'San Francisco' AND prcp > 0.0;
345
353
</programlisting>
346
354
Result:
347
355
<screen>
@@ -354,16 +362,43 @@ SELECT * FROM weather
354
362
355
363
<para>
356
364
<indexterm><primary>ORDER BY</primary></indexterm>
365
+
366
+ You can request that the results of a query
367
+ be returned in sorted order:
368
+
369
+ <programlisting>
370
+ SELECT * FROM weather
371
+ ORDER BY city;
372
+ </programlisting>
373
+
374
+ <screen>
375
+ city | temp_lo | temp_hi | prcp | date
376
+ ---------------+---------+---------+------+------------
377
+ Hayward | 37 | 54 | | 1994-11-29
378
+ San Francisco | 43 | 57 | 0 | 1994-11-29
379
+ San Francisco | 46 | 50 | 0.25 | 1994-11-27
380
+ </screen>
381
+
382
+ In this example, the sort order isn't fully specified, and so you
383
+ might get the San Francisco rows in either order. But you'd always
384
+ get the results shown above if you do
385
+
386
+ <programlisting>
387
+ SELECT * FROM weather
388
+ ORDER BY city, temp_lo;
389
+ </programlisting>
390
+ </para>
391
+
392
+ <para>
357
393
<indexterm><primary>DISTINCT</primary></indexterm>
358
394
<indexterm><primary>duplicate</primary></indexterm>
359
395
360
- As a final note, you can request thatthe results of a query can
361
- be returned in sorted order or with duplicate rows removed :
396
+ You can request thatduplicate rows be removed from the result of
397
+ a query :
362
398
363
399
<programlisting>
364
400
SELECT DISTINCT city
365
- FROM weather
366
- ORDER BY city;
401
+ FROM weather;
367
402
</programlisting>
368
403
369
404
<screen>
@@ -374,8 +409,26 @@ SELECT DISTINCT city
374
409
(2 rows)
375
410
</screen>
376
411
377
- <literal>DISTINCT</literal> and <literal>ORDER BY</literal> can be
378
- used separately, of course.
412
+ Here again, the result row ordering might vary.
413
+ You can ensure consistent results by using <literal>DISTINCT</literal> and
414
+ <literal>ORDER BY</literal> together:
415
+ <footnote>
416
+ <para>
417
+ In some database systems, including older versions of
418
+ <productname>PostgreSQL</productname>, the implementation of
419
+ <literal>DISTINCT</literal> automatically orders the rows and
420
+ so <literal>ORDER BY</literal> is redundant. But this is not
421
+ required by the SQL standard, and current
422
+ <productname>PostgreSQL</productname> doesn't guarantee that
423
+ <literal>DISTINCT</literal> causes the rows to be ordered.
424
+ </para>
425
+ </footnote>
426
+
427
+ <programlisting>
428
+ SELECT DISTINCT city
429
+ FROM weather
430
+ ORDER BY city;
431
+ </programlisting>
379
432
</para>
380
433
</sect1>
381
434