Kohei KaiGai 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.
>>> 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. > Even if we had a hash collision, each hash entry can have the original > key itself to be compared. But anyway, I love the idea to support > an opaque pointer to track particular remote-row rather. Me too. >>> Do we have some other reasonable ideas? > I'm not certain whether the duration of TupleTableSlot is enough to > carry a private datum between scan and modify stage. > Is it possible to utilize ctid field to move a private pointer? > TID data type is internally represented as a pointer to ItemPointerData, > so it has enough width to track an opaque formed remote-row identifier; > including string, int64 or others. > > One disadvantage is "ctid" system column shows a nonsense value > when user explicitly references this system column. But it does not > seems to me a fundamental problem, because we didn't give any > special meaning on the "ctid" field of foreign table. I can't say if (ab)using the field that way would cause other problems, but I don't think that "nonsense values" are a problem. The pointer would stay the same for the duration of the foreign scan, which I think is as good a ctid for a foreign table as anybody should reasonably ask. BTW, I see the following comment in htup.h: * t_self and t_tableOid should be valid if the HeapTupleData points to * a disk buffer, or if it represents a copy of a tuple on disk. They * should be explicitly set invalid in manufactured tuples. I don't know if "invalid" means "zero" in that case. 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
