Re: [v9.3] writable foreign tables

Tom Lane wrote:
> Kohei KaiGai <kaigai@kaigai.gr.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"?

Yours,
Laurenz Albe