Re: Problem while updating a foreign table pointing to apartitioned table on foreign server

Hello, thank you for the comment.

At Wed, 01 Aug 2018 21:21:57 +0900, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote in
<5B61A5E5.6010707@lab.ntt.co.jp>
> (2018/06/12 12:19), Kyotaro HORIGUCHI wrote:
> > I have demonstrated and actually shown a problem of the
> > PARAM_EXEC case.
> 
> > A. Just detecting and reporting/erroring the problematic case.
> >
> > B. Giving to Sort-like nodes an ability to convert PARAMS into
> >     junk columns.
> >
> > C. Adding a space for 64bit tuple identifier in a tuple header.
> >
> > D. Somehow inhibiting tuple-storing node like Sort between. (This
> >    should break something working.)
> >
> >
> > B seems to have possibility to fix this but I haven't have a
> > concrete design of it.
> 
> I'm just wondering whether we could modify the planner (or executor)
> so that Params can propagate up to the ModifyTable node through all
> joins like Vars/PHVs.

Yeah, it's mentioned somewhere upthread. The most large obstacle
in my view is the fact that the tuple descriptor for an
RTE_RELATION baserel is tied with the relation definition. So we
need to separate the two to use "(junk) Vars/PHVs" to do that
purpose. The four above is based on the premise of EXEC_PARAMS.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center