Re: BUG #19579: Wrong results regression

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.

Regards,
Ayush