Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master - Mailing list pgsql-hackers

From David Rowley
Subject Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
Date
Msg-id CAApHDvp6KqU=h98x4AQ-nshre6Mzi7+BHvgcKo06C627i9PLNg@mail.gmail.com
Whole thread Raw
In response to Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
List pgsql-hackers
On Wed, 24 Sept 2025 at 02:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Is there anything we can salvage from 67a54b9e, or should
> we just revert it?

It doesn't seem great that we need to reconsider the safety of that
optimisation post-release. It's not as if 67a54b9e added several cases
to test for and got one of them wrong. It's a case of the 1 case it
did add wasn't fully thought through.

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:

create or replace function one() returns int as $$ begin return 1;
end; $$ stable language plpgsql;
SELECT 'XXX',count(*) FROM t GROUP BY ROLLUP(id) HAVING NOT one()=1;

which isn't known at plan-time. For me, I can't see how to make this
safe and I suspect due to your above question that you're in a similar
situation. Reverting and reconsidering for v19 seems like the safest
option.

Let's see what Richard thinks.

David



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: GNU/Hurd portability patches
Next
From: Ajin Cherian
Date:
Subject: Re: Clear logical slot's 'synced' flag on promotion of standby