Re: BUG #19579: Wrong results regression

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().

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.

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.
*/

David