Re: [v9.3] writable foreign tables - Mailing list pgsql-hackers

2012/8/28 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> 2012/8/28 Tom Lane <tgl@sss.pgh.pa.us>:
>> Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>>>> 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.
>>
> Hmm. It seems to me a straight-forward solution rather than ab-use
> of ctid system column. Probably, cstring data type is more suitable
> to carry a private datum between scan and modify stage.
>
> One problem I noticed is how FDW driver returns an extra field that
> is in neither system nor regular column.
> Number of columns and its data type are defined with TupleDesc of
> the target foreign-table, so we also need a feature to extend it on
> run-time. For example, FDW driver may have to be able to extend
> a "virtual" column with cstring data type, even though the target
> foreign table does not have such a column.
>
I tried to investigate the related routines.

TupleDesc of TupleTableSlot associated with ForeignScanState
is initialized at ExecInitForeignScan as literal.
ExecAssignScanType assigns TupleDesc of the target foreign-
table on tts_tupleDescriptor, "as-is".
It is the reason why IterateForeignScan cannot return a private
datum except for the columns being declared as regular ones.

Confrontation between ForeignScan and SubqueryScan tell us
the point to be extended. It assigns TupleDesc of the subplan
generated at run-time.
It seems to me ForeignScan will be able to adopt similar idea;
that allows to append "pseudo-column" onto TupleDesc to
carry identifier of remote-rows to be updated / deleted, if
FDW driver can control TupleDesc being set, instead of the
one come from relation's definition as-is.

Any comment please. Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>