Re: pgsql: Make the behavior of HAVING without GROUP

Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Tom Lane wrote:
>> Make the behavior of HAVING without GROUP BY conform to the SQL spec.

> I wonder how much back-compatibility and dump reloading problems this
> might cause? :(

Could happen, but considering that this has been wrong for circa five
years and no one noticed, I think it's unlikely to be a widespread
issue.

For the record, it looks like I introduced the faulty
HAVING-equals-WHERE meme in this patch, which was released in 7.0:

1999-10-07 00:23 tgl

* src/: backend/commands/view.c, backend/executor/execMain.c,
backend/nodes/copyfuncs.c, backend/nodes/equalfuncs.c,
backend/nodes/outfuncs.c, backend/nodes/readfuncs.c,
backend/optimizer/plan/initsplan.c,
backend/optimizer/plan/planmain.c,
backend/optimizer/plan/planner.c, backend/optimizer/util/clauses.c,
backend/parser/analyze.c, backend/parser/gram.y,
backend/parser/parse_agg.c, backend/parser/parse_clause.c,
backend/parser/parse_func.c, backend/parser/parse_relation.c,
backend/rewrite/rewriteHandler.c, include/nodes/parsenodes.h,
include/optimizer/planmain.h, include/parser/parse_relation.h,
test/regress/expected/rules.out: Fix planner and rewriter to follow
SQL semantics for tables that are mentioned in FROM but not
elsewhere in the query: such tables should be joined over anyway.
Aside from being more standards-compliant, this allows removal of
some very ugly hacks for COUNT(*) processing. Also, allow HAVING
clause without aggregate functions, since SQL does. Clean up
CREATE RULE statement-list syntax the same way Bruce just fixed the
main stmtmulti production. CAUTION: addition of a field to
RangeTblEntry nodes breaks stored rules; you will have to initdb if
you have any rules.

Mind you, our processing of HAVING was not *right* before that; it
was even more broken ...

regards, tom lane