Re: [v9.3] writable foreign tables - Mailing list pgsql-hackers

2012/8/28 Albe Laurenz <laurenz.albe@wien.gv.at>:
> 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 tuple on disk.  They
>  * should be explicitly set invalid in manufactured tuples.
>
> I don't know if "invalid" means "zero" in that case.
>
ItemPointerSetInvalid is declared as follows:

/** ItemPointerSetInvalid*      Sets a disk item pointer to be invalid.*/
#define ItemPointerSetInvalid(pointer) \
( \   AssertMacro(PointerIsValid(pointer)), \   BlockIdSet(&((pointer)->ip_blkid), InvalidBlockNumber), \
(pointer)->ip_posid= InvalidOffsetNumber \
 
)

Since ItemPointerGetBlockNumber() and ItemPointerGetOffsetNumber()
checks whether the given ItemPointer is valid, FDWs may have to put
a dummy ItemPointerData on head of their private datum to avoid
the first 6-bytes having zero.

For example, the following data structure is safe to carry an opaque
datum without false-positive of invalid ctid.

typedef struct {   ItemPointerData   dumm   char *pk_of_remote_table;
} my_pseudo_rowid;

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