Re: [v9.3] writable foreign tables

2012/9/13 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>:
> Tom Lane wrote:
>> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>>> Laurenz Albe wrote:
>>>> Would it be too invasive to introduce a new pointer in
> TupleTableSlot
>>>> that is NULL for anything but virtual tuples from foreign tables?
>
>>> I'm not certain whether the duration of TupleTableSlot is enough to
>>> carry a private datum between scan and modify stage.
>
>> It's not.
>
>>> Is it possible to utilize ctid field to move a private pointer?
>
>> UPDATEs and DELETEs do not rely on the ctid field of tuples to carry
> the
>> TID from scan to modify --- in fact, most of the time what the modify
>> step is going to get is a "virtual" TupleTableSlot that hasn't even
>> *got* a physical CTID field.
>>
>> Instead, the planner arranges for the TID to be carried up as an
>> explicit resjunk column named ctid. (Currently this is done in
>> rewriteTargetListUD(), but see also preptlist.c which does some
> related
>> things for SELECT FOR UPDATE.)
>>
>> I'm inclined to think that what we need here is for FDWs to be able to
>> modify the details of that behavior, at least to the extent of being
>> able to specify a different data type than TID for the row
>> identification column.
>
> Would that imply inventing a new system attribute for
> "foreign tid"?
>
It is an idea to implement this feature with minimum code side.

However, my preference is to support "pseudo-column" approach
rather than system columns, because it also can be utilized for
another interesting feature that enables to push-down target entry
onto remote side.
So, I'd like to try to support a feature that allows foreign-table to
return "pseudo-column" in addition to its table definition to move
row-id of remote tuples, as primary purpose of this.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>