aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2005-03-10 23:21:26 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2005-03-10 23:21:26 +0000
commit595ed2a8550e34c0abe64569a104d92ad077ec08 (patch)
tree004764220f537256d96637d5a119fd2086ed40ec /doc/src
parent609e32b929cf8684f8ae3a2b9f1655b372fb8b85 (diff)
downloadpostgresql-595ed2a8550e34c0abe64569a104d92ad077ec08.tar.gz
postgresql-595ed2a8550e34c0abe64569a104d92ad077ec08.zip
Make the behavior of HAVING without GROUP BY conform to the SQL spec.
Formerly, if such a clause contained no aggregate functions we mistakenly treated it as equivalent to WHERE. Per spec it must cause the query to be treated as a grouped query of a single group, the same as appearance of aggregate functions would do. Also, the HAVING filter must execute after aggregate function computation even if it itself contains no aggregate functions.
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/query.sgml7
-rw-r--r--doc/src/sgml/ref/select.sgml13
2 files changed, 16 insertions, 4 deletions
diff --git a/doc/src/sgml/query.sgml b/doc/src/sgml/query.sgml
index 366820e5546..e573db56cb6 100644
--- a/doc/src/sgml/query.sgml
+++ b/doc/src/sgml/query.sgml
@@ -1,5 +1,5 @@
<!--
-$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.43 2005/01/22 22:56:36 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/query.sgml,v 1.44 2005/03/10 23:21:20 tgl Exp $
-->
<chapter id="tutorial-sql">
@@ -783,8 +783,9 @@ SELECT city, max(temp_lo)
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
- could be used more efficiently at the <literal>WHERE</literal> stage.)
+ clause that doesn't use aggregates, but it's seldom useful. The same
+ condition could be used more efficiently at the <literal>WHERE</literal>
+ stage.)
</para>
<para>
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 855412c36c9..93218e16c2e 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1,5 +1,5 @@
<!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.81 2005/01/22 23:22:19 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/select.sgml,v 1.82 2005/03/10 23:21:20 tgl Exp $
PostgreSQL documentation
-->
@@ -452,6 +452,17 @@ HAVING <replaceable class="parameter">condition</replaceable>
unambiguously reference a grouping column, unless the reference
appears within an aggregate function.
</para>
+
+ <para>
+ The presence of <literal>HAVING</literal> turns a query into a grouped
+ query even if there is no <literal>GROUP BY</> clause. This is the
+ same as what happens when the query contains aggregate functions but
+ no <literal>GROUP BY</> clause. All the selected rows are considered to
+ form a single group, and the <command>SELECT</command> list and
+ <literal>HAVING</literal> clause can only reference table columns from
+ within aggregate functions. Such a query will emit a single row if the
+ <literal>HAVING</literal> condition is true, zero rows if it is not true.
+ </para>
</refsect2>
<refsect2 id="sql-select-list">