From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Kohei KaiGai *EXTERN*" <kaigai(at)kaigai(dot)gr(dot)jp> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "PgHacker" <pgsql-hackers(at)postgresql(dot)org>, "Shigeru Hanada" <shigeru(dot)hanada(at)gmail(dot)com> |
Subject: | Re: [v9.3] writable foreign tables |
Date: | 2012-08-28 09:16:05 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C2084EFD83@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-08-28 09:40:09 | Re: [v9.3] writable foreign tables |
Previous Message | Kohei KaiGai | 2012-08-28 09:07:31 | Re: [v9.3] writable foreign tables |