On Mon, Apr 16, 2018 at 7:35 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > It does fix the problem. But the patch as is interferes with the way > we handle tableoid currently. That can be seen from the regression > diffs that the patch causes. RIght now, every tableoid reference gets > converted into the tableoid of the foreign table (and not the tableoid > of the foreign table). Somehow we need to differentiate between the > tableoid injected for DML and tableoid references added by the user in > the original query and then use tableoid on the foreign server for the > first and local foreign table's oid for the second. Right now, I don't > see a simple way to do that.
I think that the place to start would be to change this code to use something other than TableOidAttributeNumber: + var = makeVar(parsetree->resultRelation, + TableOidAttributeNumber, + OIDOID, + -1, + InvalidOid, + 0); Note that rewriteTargetListUD, which calls AddForeignUpdateTargets, also contingently adds a "wholerow" attribute which ExecModifyTable() is able to fish out later. It seems like it should be possible to add a "remotetableoid" column that works similarly, although I'm not exactly sure what would be involved. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
