Re: Wrong results with subquery pullup and grouping sets

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong results with subquery pullup and grouping sets
Date: 2025-03-12 09:28:52
Message-ID: CAEZATCX0bY+Z3dnAr2GAJX-sXvtmV3YG0hhobaJR91HgwCbOGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 12 Mar 2025 at 07:45, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>
> I refined the comment in v2 and ended up with:
>
> * This analysis could be tighter: in particular, a non-strict
> * construct hidden within a lower-level PlaceHolderVar is not
> * reason to add another PHV. But for now it doesn't seem
> - * worth the code to be more exact.
> + * worth the code to be more exact. This is also why it's
> + * preferable to handle bare PHVs in the above branch, rather
> + * than this branch. We also prefer to handle bare Vars in a
> + * separate branch, as it's cheaper this way and parallels the
> + * handling of PHVs.
>

LGTM.

> For backpatching, 0001 seems more like a cosmetic change, and I don't
> think it needs to be backpatched. 0002 is a bug fix, but I'm not
> confident enough to commit it to the back branches. Given that there
> are other wrong result issues with grouping sets fixed in version 18
> but not in earlier versions, and that there are no field reports about
> this issue, perhaps it's OK to refrain from backpatching this one?
>

Yes, I was thinking along the same lines. This particular issue feels
a bit manufactured, and unlikely to occur in practice, but I'm happy
to go with whatever you decide.

Thanks for taking care of this.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-03-12 09:30:02 Re: SQL function which allows to distinguish a server being in point in time recovery mode and an ordinary replica
Previous Message Anthonin Bonnefoy 2025-03-12 09:13:06 Re: Memory context can be its own parent and child in replication command