Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
От | Robert Haas |
---|---|
Тема | Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers |
Дата | |
Msg-id | CA+TgmoatDRcBJ=7kchoyZAwT7yR_bZvUoEB5EPU_QhmGf8D80A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
|
Список | pgsql-hackers |
On Fri, May 11, 2018 at 8:46 AM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote: > I added an assertion test to make_modifytable to match that in > create_modifytable_path. Attached is an updated version of the patch. Committed. Was it just good luck that this ever worked at all? I mean: - if (rti < root->simple_rel_array_size && - root->simple_rel_array[rti] != NULL) + if (rti < subroot->simple_rel_array_size && + subroot->simple_rel_array[rti] != NULL) { - RelOptInfo *resultRel = root->simple_rel_array[rti]; + RelOptInfo *resultRel = subroot->simple_rel_array[rti]; fdwroutine = resultRel->fdwroutine; } else { - RangeTblEntry *rte = planner_rt_fetch(rti, root); + RangeTblEntry *rte = planner_rt_fetch(rti, subroot); ...an RTI is only meaningful relative to a particular PlannerInfo's range table. It can't be right to just take an RTI for one PlannerInfo and look it up in some other PlannerInfo's range table. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: