Re: BUG #19579: Wrong results regression

Hi,

On Tue, 28 Jul 2026 at 11:18, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
wrote:

> Hi,
>
> On Tue, 28 Jul 2026 at 06:08, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
>> On Tue, 28 Jul 2026 at 00:38, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
>> wrote:
>> > I spent some time on this one. If I'm reading it right, the bisect to
>> > f2bae51dfd5 seems to point at create_gating_plan(): when it stacks a
>> > gating Result over an existing Result, it now absorbs the child
>> > unconditionally, whereas before it only did that for a "trivial" child
>> > (no subplan and no resconstantqual). So when the child carries a
>> > one-time filter, that filter looks like it just gets dropped, which
>> would
>> > explain the missing "NULL <> 7" gate in the reported plan.
>>
>> I was looking at this last night and came to the same conclusion about
>> the mistake in create_gating_plan().
>>
>
> Thanks for the review!
>
>
>> The test case can be simplified to:
>>
>> select * from (
>> select c0 from (select null::int as c0 from ((select 1) union all
>> (select 2))) t1
>> full join (select 1) t2 on true
>> where c0 is not null
>> ) t3 where now() is not null;
>>
>> I'm not sure it's worth verifying the EXPLAIN output in the test as
>> the important part here is the result. It might not be inconceivable
>> that someone might want to chain the resconstantqual in the future
>> with:
>>
>> gplan->resconstantqual = (Node *) list_concat((List *)
>> gplan->resconstantqual, (List *) rplan->resconstantqual);
>>
>> and reduce to a single Result node.
>>
>
> Sounds good, I changed it to just the select statement.
>
>
>> I've included Robert here as I'm not all that certain why this change
>> was made. I suspect it was a misunderstanding of the comment "We might
>> have had a trivial Result plan already", where "trivial" is not well
>> defined. If that's the case, then I think the comments need work. Two
>> paragraphs seem a little excessive. Wouldn't the following suffice?
>>
>> /*
>> * See if we can reduce down stacked Result nodes to a single node. This
>> * is only possible when the nested Result has no subplan and no gating
>> * qual. If we do remove the nested Result, we maintain the relids and
>> * result_type for EXPLAIN.
>> */
>>
>
> Modified the comment as suggested above.
>
> v2 patch attached.
>

I've opened a commitfest item for this:
https://commitfest.postgresql.org/patch/7078/

Should it be in the Pg 19 open list too?

Regards,
Ayush