Re: FDW: possible resjunk columns in AddForeignUpdateTargets

2013/12/5 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>:
> 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.

Thanks for confirming that, I suspected that might be the case. I'll
have to go for Plan B (or C or D).

Regards

Ian Barwick