WHERE filters rows before grouping; HAVING filters groups after — a misplaced HAVING filters the wrong thing.

Same logical-order story as the window-in-WHERE atom, one floor down: at WHERE time, groups don't exist, so a group property is unaskable — hence a binder error, not a wrong answer. The performance corollary: conditions on raw rows belong in WHERE even when HAVING would accept them, because WHERE prunes before the group work and HAVING after.

SELECT
  pilot,
  SUM(passengers) FROM
  rides
WHERE
  SUM(passengers) > 3
GROUP BY
  pilot
ORDER BY
  pilot;

SELECT
  pilot,
  SUM(passengers) AS total
FROM
  rides
GROUP BY
  pilot
HAVING
  SUM(passengers) > 3
ORDER BY
  pilot;

Filtering SUM(passengers) in WHERE raised a binder error — at WHERE time the groups don't exist yet, so an aggregate is unaskable; it belongs in HAVING.

The two-clause split by what's being tested — rows → WHERE, group properties → HAVING; never row-filters in HAVING.