Re: BUG #19653: "variable not found in subplan target list" during planning with parallel parameterized nested loop,

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Mon, Sep 7, 2026 at 2:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hmm, I'm not enamored of just union'ing the top_parent_relids with the
>> regular relids. I don't see us doing that anywhere else, so it smells
>> like a shortcut. Shouldn't we remove the child relids while adding
>> the parent relids?

> Yeah, we don't union child relids and parent relids anywhere else, and
> I'm not entirely happy with it either. But I'm not sure we can simply
> remove the child relids here, because the same set is used for two
> different membership tests. For Vars, we check whether var->varno is
> a member of the set, and within a child join the Vars carry child
> relids. For PlaceHolderVars, we check whether ph_eval_at is a subset
> of the set, and ph_eval_at always carries parent relids. So, AFAICS,
> the set needs the child relids for the Var test and the parent relids
> for the PHV test, and dropping the child relids would break the Var
> test.

Yeah, I tried adjusting things like that and the regression tests
immediately crashed. So now I think we have to do it as you have it;
but maybe the comment could be improved to explain that we need to
match both Vars having the child relid and PHVs having top-parent
relids. (Could there be Vars having the parent relid? Not sure,
but if there are, I suppose we'd need to match them too.)

> Maybe an alternative is to keep the set in top-parent terms and
> translate each Var's varno to its top parent before the membership
> test, or to leave the set alone and instead translate ph_eval_at into
> child relids before the subset test. But AFAICS we need to update
> quite a few places to make either way work, such as
> replace_nestloop_params_mutator(), identify_current_nestloop_params(),
> process_subquery_nestloop_params(), and maybe more. Not sure if this
> is a better option.

Agreed. Quite aside from the number of places that'd have to be
touched, I'm not too comfortable with rethinking those design
decisions in a hasty back-patch. It seems not unlikely that
extensions contain code that expects the current data structure
definitions.

regards, tom lane