Kohei KaiGai wrote: > 2012/8/25 Robert Haas <robertmh...@gmail.com>: >> On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: >>> It is a responsibility of FDW extension (and DBA) to ensure each >>> foreign-row has a unique identifier that has 48-bits width integer >>> data type in maximum.
>> It strikes me as incredibly short-sighted to decide that the row >> identifier has to have the same format as what our existing heap AM >> happens to have. I think we need to allow the row identifier to be of >> any data type, and even compound. For example, the foreign side might >> have no equivalent of CTID, and thus use primary key. And the primary >> key might consist of an integer and a string, or some such. > I assume it is a task of FDW extension to translate between the pseudo > ctid and the primary key in remote side. > > For example, if primary key of the remote table is Text data type, an idea > is to use a hash table to track the text-formed primary being associated > with a particular 48-bits integer. The pseudo ctid shall be utilized to track > the tuple to be modified on the scan-stage, then FDW can reference the > hash table to pull-out the primary key to be provided on the prepared > statement. And what if there is a hash collision? Then you would not be able to determine which row is meant. I agree with Robert that this should be flexible enough to cater for all kinds of row identifiers. Oracle, for example, uses ten byte identifiers which would give me a headache with your suggested design. > Do we have some other reasonable ideas? Would it be too invasive to introduce a new pointer in TupleTableSlot that is NULL for anything but virtual tuples from foreign tables? 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