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