On Tue, Sep 29, 2026 at 2:57 PM Matemática A3K <[email protected]> wrote:
> > > On Tue, Sep 29, 2026 at 10:33 AM David Rowley <[email protected]> > wrote: > >> On Tue, 29 Sept 2026 at 21:34, PG Doc comments form >> <[email protected]> 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 >
