[Minor] Correctness in sentence in "Aggregate Functions"

On Tue, 29 Sept 2026 at 21:34, PG Doc comments form
<noreply@postgresql.org> wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/tutorial-agg.html
Description:

Where it says "In the previous example, we can apply the city name
restriction in WHERE, since it needs no aggregate.",
should say "In the previous example, we apply the city name restriction in
WHERE since it needs no aggregate."
which I find to be more correct.

i.e you want to remove the word "can" and remove a comma.

I disagree with this being an improvement. The text is trying to
convey that it's more efficient to put the "city" qual in the WHERE
clause, even though it technically *could* go in the HAVING clause. If
you remove "can" then that makes it sound more like putting it in the
HAVING clause is invalid. It's not. The text explains it's just more
efficient to filter before grouping.

David

On Tue, Sep 29, 2026 at 2:57 PM Matemática A3K <matematica.a3k@gmail.com>
wrote:

On Tue, Sep 29, 2026 at 10:33 AM David Rowley <dgrowleyml@gmail.com>
wrote:

On Tue, 29 Sept 2026 at 21:34, PG Doc comments form
<noreply@postgresql.org> wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/18/tutorial-agg.html
Description:

Where it says "In the previous example, we can apply the city name
restriction in WHERE, since it needs no aggregate.",
should say "In the previous example, we apply the city name restriction

in

WHERE since it needs no aggregate."
which I find to be more correct.

i.e you want to remove the word "can" and remove a comma.

Indeed, in the proof-reading that I am performing on the book, this
short-circuited me. I understand the development process may be heavy for
small changes, especially for documentation, yet it seemed worthy to me - I
understand it may not be for you.

I disagree with this being an improvement. The text is trying to
convey that it's more efficient to put the "city" qual in the WHERE
clause, even though it technically *could* go in the HAVING clause. If
you remove "can" then that makes it sound more like putting it in the
HAVING clause is invalid. It's not. The text explains it's just more
efficient to filter before grouping.

Your clarification makes total sense, although I still find the document
hard to read. IMO, it would be better like this:
---
It is important to understand the interaction between aggregates and SQL's
WHERE and HAVING clauses.

The fundamental difference between WHERE and HAVING is:

- WHERE selects input rows before groups and aggregates are computed
(thus, it controls which rows go into the aggregate computation), and,

- HAVING selects group rows after groups and aggregates are computed.

The WHERE clause *must not contain aggregate functions*; it makes no sense
to try to use an aggregate to determine which rows will be inputs to the
aggregates.

The HAVING clause should *always contain aggregate functions*. (Although
you are allowed to write a HAVING clause that doesn't use aggregates, it's
seldom useful - the same condition could be used more efficiently at the
WHERE stage.)

In the previous example, we can apply the city name restriction in WHERE,
since it needs no aggregate, and in HAVING, since it can be computed.

It is more efficient adding the restriction to WHERE instead of HAVING
because we avoid doing the grouping and aggregate calculations for all rows
that fail the WHERE check.

Also, it is in line with the designed purpose of the clauses, which may
result in improved readability and/or consistency in your queries*.
---

*: There should be a benefit in using the clauses as intended ("The HAVING
clause should always contain aggregate functions") instead of hacks (it
works from unintended use) , but I am having trouble finding the words for
that benefit.

Any thoughts?

Standardization? "Also, it is in line with the designed purpose of the
clauses, which may benefit from standardization."?