aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2000-01-27 18:11:50 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2000-01-27 18:11:50 +0000
commitdd979f66be20fc54aad06da743f788fbc505bbe1 (patch)
tree4d6b578e0afc7dc0198296940cd77c79c5eff66c /doc/src
parent3f0074e403ac3a145c5e43db3348f45fe084703d (diff)
downloadpostgresql-dd979f66be20fc54aad06da743f788fbc505bbe1.tar.gz
postgresql-dd979f66be20fc54aad06da743f788fbc505bbe1.zip
Redesign DISTINCT ON as discussed in pgsql-sql 1/25/00: syntax is now
SELECT DISTINCT ON (expr [, expr ...]) targetlist ... and there is a check to make sure that the user didn't specify an ORDER BY that's incompatible with the DISTINCT operation. Reimplement nodeUnique and nodeGroup to use the proper datatype-specific equality function for each column being compared --- they used to do bitwise comparisons or convert the data to text strings and strcmp(). (To add insult to injury, they'd look up the conversion functions once for each tuple...) Parse/plan representation of DISTINCT is now a list of SortClause nodes. initdb forced by querytree change...
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/ref/select.sgml29
1 files changed, 21 insertions, 8 deletions
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 070f8b43d0f..ed180ac91c1 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1,5 +1,5 @@
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.23 1999/12/13 17:39:38 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/select.sgml,v 1.24 2000/01/27 18:11:25 tgl Exp $
Postgres documentation
-->
@@ -22,7 +22,7 @@ Postgres documentation
<date>1999-07-20</date>
</refsynopsisdivinfo>
<synopsis>
-SELECT [ ALL | DISTINCT [ ON <replaceable class="PARAMETER">column</replaceable> ] ]
+SELECT [ ALL | DISTINCT [ ON ( <replaceable class="PARAMETER">expression</replaceable> [, ...] ) ] ]
<replaceable class="PARAMETER">expression</replaceable> [ AS <replaceable class="PARAMETER">name</replaceable> ] [, ...]
[ INTO [ TEMPORARY | TEMP ] [ TABLE ] <replaceable class="PARAMETER">new_table</replaceable> ]
[ FROM <replaceable class="PARAMETER">table</replaceable> [ <replaceable class="PARAMETER">alias</replaceable> ] [, ...] ]
@@ -201,17 +201,30 @@ SELECT [ ALL | DISTINCT [ ON <replaceable class="PARAMETER">column</replaceable>
</para>
<para>
- <command>DISTINCT</command> will eliminate all duplicate rows from the
+ <command>DISTINCT</command> will eliminate duplicate rows from the
result.
- <command>DISTINCT ON <replaceable class="PARAMETER">column</replaceable></command>
- will eliminate all duplicates in the specified column; this is
- similar to using
- <command>GROUP BY <replaceable class="PARAMETER">column</replaceable></command>.
- <command>ALL</command> will return all candidate rows,
+ <command>ALL</command> (the default) will return all candidate rows,
including duplicates.
</para>
<para>
+ <command>DISTINCT ON</command> eliminates rows that match on all the
+ specified expressions, keeping only the first row of each set of
+ duplicates. Note that "the first row" of each set is unpredictable
+ unless <command>ORDER BY</command> is used to ensure that the desired
+ row appears first. For example,
+ <programlisting>
+ SELECT DISTINCT ON (location) location, time, report
+ FROM weatherReports
+ ORDER BY location, time DESC;
+ </programlisting>
+ retrieves the most recent weather report for each location. But if
+ we had not used ORDER BY to force descending order of time values
+ for each location, we'd have gotten a report of unpredictable age
+ for each location.
+ </para>
+
+ <para>
The GROUP BY clause allows a user to divide a table
conceptually into groups.
(See <xref linkend="sql-groupby" endterm="sql-groupby-title">.)