On Wed, May 16, 2018 at 11:31 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
As of today, all the attributes added by AddForeignUpdateTargets hook of postgres_fdw are recognised by PostgreSQL. But remotetableoid is not a recognised attributes. In order to use it, we either have to define a new system attribute "remotetableoid" or add a user defined attribute "remotetableoid" in every foreign table. The first one will be very specific for postgres_fdw and other FDWs won't be able to use it. The second would mean that SELECT * from foreign table reports remotetableoid as well, which is awkward. Me and Horiguchi-san discussed those ideas in this mail thread. Anyway, my comment to which you have replied is obsolete now. I found a solution to that problem, which I have implemented in 0003 in the latest patch-set I have shared. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company