Re: [PATCH] Fix grouping-set nulling of variable-free grouping expressions

Hi Shihao,

Thanks for confirming, and for the additional examples.

The HAVING case is another good demonstration of why structural
matching should exclude grouping items without a level-zero Var.
The constant in HAVING is independent of the grouped target entry,
so it should not be replaced by a group Var.

I also agree that the now() example should retain the PG18/master
behavior (f, f). The independently written now() expression does
not reference the grouping output merely because it is structurally
equal.

I've tested a prototype combining the two parser rules with v3's
PHV-sharing change, with encouraging results so far. I'll verify
these two examples explicitly and add them to the regression tests
before posting a revision.

I'd still like to hear Tom's thoughts on the level-zero-Var rule,
since that determines the intended semantics of these cases.

Thanks,
Haibo

On Tue, Oct 20, 2026 at 5:48 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Haibo,
>
> I agree with both rules. On your CUBE example, 17 and 18 also give 2 rows,
> so master's 4 is right.
>
> v3 alone has one more problem. SELECT 1 AS x GROUP BY ROLLUP(x) HAVING 1
> IS NOT NULL returns 2 rows on master but 1 with v3. The parser turns the
> 1 in HAVING into a GROUP Var.
>
> A question on (b). SELECT now() IS NULL AS n GROUP BY ROLLUP(now())
> gives f and t on 17 and with v3, but f and f on 18 and master. (b)
> should keep f and f, which seems fine to me.
>
> Thanks,
> Shihao
>