Re: [v9.3] writable foreign tables

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
tupleon disk.  They* should be explicitly set invalid in manufactured tuples. 

I don't know if "invalid" means "zero" in that case.

Yours,
Laurenz Albe