Christopher Kings-Lynne <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
