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  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Postgres 11 release notes