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 <[email protected]> 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 >
