| From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | ashutosh(dot)bapat(at)enterprisedb(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)2ndquadrant(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Problem while updating a foreign table pointing to a partitioned table on foreign server |
| Date: | 2018-08-01 12:21:57 |
| Message-ID: | 5B61A5E5.6010707@lab.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
(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.
Best regards,
Etsuro Fujita
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2018-08-01 12:28:38 | doc - add missing documentation for "acldefault" |
| Previous Message | Arthur Zakirov | 2018-08-01 12:17:34 | Re: [HACKERS] Bug in to_timestamp(). |