Hello, thank you for the comment. At Wed, 01 Aug 2018 21:21:57 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote in <5b61a5e5.6010...@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
