Re: [v9.3] writable foreign tables

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