2012/9/13 Albe Laurenz <laurenz.a...@wien.gv.at>: > 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"? > It is an idea to implement this feature with minimum code side.
However, my preference is to support "pseudo-column" approach rather than system columns, because it also can be utilized for another interesting feature that enables to push-down target entry onto remote side. So, I'd like to try to support a feature that allows foreign-table to return "pseudo-column" in addition to its table definition to move row-id of remote tuples, as primary purpose of this. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
