Re: [Minor] Correctness in sentence in "Aggregate Functions"

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

>
>
> On Tue, Sep 29, 2026 at 10:33 AM David Rowley <dgrowleyml(at)gmail(dot)com>
> wrote:
>
>> On Tue, 29 Sept 2026 at 21:34, PG Doc comments form
>> <noreply(at)postgresql(dot)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."?

>
> David
>>
>
> Rodrigo
>