Re: FDW: possible resjunk columns in AddForeignUpdateTargets

Ian Lawrence Barwick wrote:
> 2013/11/8 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> [ thinks for awhile... ] Hm. In principle you can put any expression
>> you want into the tlist during AddForeignUpdateTargets. However, if it's
>> not a Var then the planner won't understand that it's something that needs
>> to be supplied by the table scan, so things won't work right in any but
>> the most trivial cases (maybe not even then :-().
>>
>> What I'd try is creating a Var that has the attno of ctid
>> (ie, SelfItemPointerAttributeNumber) but the datatype you want, ie bytea.
>> This won't match what the catalogs say your table's ctid is, but I think
>> that nothing will care much about that.
>
> Apologies for reinvigorating this thread, but I'm running into a similar wall
> myself and would like to clarify if this approach will work at all.
>
> My foreign data source is returning a fixed-length string as a unique row
> identifier; in AddForeignUpdateTargets() I can create a Var like this:
>
> var = makeVar(parsetree->resultRelation,
> SelfItemPointerAttributeNumber,
> BPCHAROID,
> 32,
> InvalidOid,
> 0);
>
> but is it possible to store something other than a TIDOID here, and if so how?

Subsequent analysis showed that this won't work as you have
no way to populate such a resjunk column.
resjunk columns seem to get filled with the values from the
column of the same name, so currently there is no way to invent
your own column, fill it and pass it on.

See thread 8b848b463a71b7a905bc5ef18b95528e(dot)squirrel(at)sq(dot)gransy(dot)com

What I ended up doing is introduce a column option that identifies
a primary key column. I add a resjunk entry for each of those and
use them to identify the correct row during an UPDATE or DELETE.

That only works for foreign data sources that have a concept of
a primary key, but maybe you can do something similar.

Yours,
Laurenz Albe