Re: foreign join error "variable not found in subplan target list"

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
Cc: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: foreign join error "variable not found in subplan target list"
Date: 2022-08-10 08:36:38
Message-ID: CAMbWs491hb2ecgG--nFiifLMyM7a+XRMK4eDse=xq1jkOkda1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Aug 10, 2022 at 3:06 PM Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
wrote:

> Richard Guo писал 2022-08-10 08:28:
> > On Wed, Aug 10, 2022 at 10:15 AM Richard Guo <guofenglinux(at)gmail(dot)com>
> > wrote:
> >
> >> Currently the outer_plan used in postgresGetForeignPlan() can only
> >> be
> >> 'Join' or 'Sort + Join'. I'm wondering whether we can take this
> >> knowledge into consideration when we fix the outer_plan's tlist, to
> >> also
> >> fix the Join's tlist if it is below the Sort node.
> >
> > Alternatively, how about we include in the EPQ path's pathtarget
> > thecolumns required for evaluating the local conditions when we
> > consider
> > EPQ paths with pathkeys? Something like attached.
> >
> > Thanks
> > Richard
>
> Hi.
> Why are we sure that epq_path can provide all vars from restrictinfo?

The local conditions come from the joinrel's restrictlist, which
contains all the clauses that syntactically belong at the join level. So
I think the join path for EPQ checks should be able to provide all the
exprs needed by local_conds.

Thanks
Richard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexander Pyhalov 2022-08-10 15:16:59 Re: foreign join error "variable not found in subplan target list"
Previous Message PG Bug reporting form 2022-08-10 08:20:30 BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time