Re: [v9.3] writable foreign tables

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"?

Yours,
Laurenz Albe