| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | 邱宇航 <iamqyh(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master |
| Date: | 2025-09-24 01:23:08 |
| Message-ID: | 3231170.1758676988@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Keisuke Kuroda | 2025-09-24 02:37:25 | Re: Add support for entry counting in pgstats |
| Previous Message | Alexandra Wang | 2025-09-24 01:05:26 | Re: SQL:2023 JSON simplified accessor support |