Обсуждение: Unclear documentation and requirement of clarification
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/18/tutorial-agg.html Description: Notice this particular section in the documentation of 2.7 Aggregrate Functions (https://www.postgresql.org/docs/current/tutorial-agg.html) : "If we wanted to know what city (or cities) that reading occurred in, we might try: SELECT city FROM weather WHERE temp_lo = max(temp_lo); -- WRONG but this will not work since the aggregate max cannot be used in the WHERE clause. (This restriction exists because the WHERE clause determines which rows will be included in the aggregate calculation; so obviously it has to be evaluated before aggregate functions are computed.) However, as is often the case the query can be restated to accomplish the desired result, here by using a subquery: SELECT city FROM weather WHERE temp_lo = (SELECT max(temp_lo) FROM weather);" This would be better off if it's mentioned that in this particular case, we actually need the aggregate function to be computed before the WHERE clause and that's why we are using a subquery.
On Thursday, April 16, 2026, 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:
(This restriction exists because the WHERE clause determines which
rows will be included in the aggregate calculation; so obviously it has to
be evaluated before aggregate functions are computed.)
This would be better off if it's mentioned that in this particular case, we
actually need the aggregate function to be computed before the WHERE clause
and that's why we are using a subquery.
That is what the parenthetical says, though without introducing the term subquery.
Without a question or a concrete proposed alternative leaving this as-is seems reasonable. I have no qualms with it at least.
David J.