Re: [v9.3] writable foreign tables

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