Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers - Mailing list pgsql-hackers

From Robert Haas
Subject Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
Date
Msg-id CA+TgmoatDRcBJ=7kchoyZAwT7yR_bZvUoEB5EPU_QhmGf8D80A@mail.gmail.com
Whole thread Raw
In response to Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: postgres_fdw: Oddity in pushing down inherited UPDATE/DELETEjoins to remote servers
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing unneeded self joins
Next
From: Magnus Hagander
Date:
Subject: Re: Postgres 11 release notes