Re: [v9.3] writable foreign tables

Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)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.

regards, tom lane