Horton

Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: 邱宇航 <iamqyh@gmail.com>, Richard Guo <guofenglinux@gmail.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-09-24T01:23:08Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix test case from 40c242830

  2. Fix pushdown of degenerate HAVING clauses

  3. Allow pushdown of HAVING clauses with grouping sets

  4. Mark expressions nullable by grouping sets

David Rowley <dgrowleyml@gmail.com> writes:
> As for fixing it; testing for a Const-false havingClause can't be done
> as that only works for this case which const-folding happens to figure
> out during planning. You could equally have something Var-less like:

Yeah, I don't think the havingClause being constant-false is the
key point here.  I've not looked closely at 67a54b9e, but I suspect
that anything Var-free is potentially an issue.  Or it might even
fail for something that has Vars but is non-strict.

The core of the problem though is that the aggregation node will
issue an all-nulls row that did not come from its input, and we
have to be sure that the HAVING clause is properly evaluated
for that row.

			regards, tom lane