Kohei KaiGai <kai...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers