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
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 |