Re: [v9.3] writable foreign tables

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.

Do we have some other reasonable ideas?

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>