Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server
В списке pgsql-hackers по дате отправления:
| От | Etsuro Fujita |
|---|---|
| Тема | Re: Problem while updating a foreign table pointing to a partitionedtable on foreign server |
| Дата | |
| Msg-id | 5B61A5E5.6010707@lab.ntt.co.jp обсуждение |
| Ответ на | Re: Problem while updating a foreign table pointing to apartitioned table on foreign server (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
| Ответы |
Re: Problem while updating a foreign table pointing to apartitioned table on foreign server
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера