Kohei KaiGai wrote:
> 2012/8/25 Robert Haas <robertmhaas@gmail.com>:
>> On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai <kaigai@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