From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kohei KaiGai" <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-09-13 13:46:02 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C2086C1360@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>> Laurenz Albe wrote:
>>> Would it be too invasive to introduce a new pointer in
TupleTableSlot
>>> that is NULL for anything but virtual tuples from foreign tables?
>> I'm not certain whether the duration of TupleTableSlot is enough to
>> carry a private datum between scan and modify stage.
> It's not.
>> Is it possible to utilize ctid field to move a private pointer?
> UPDATEs and DELETEs do not rely on the ctid field of tuples to carry
the
> TID from scan to modify --- in fact, most of the time what the modify
> step is going to get is a "virtual" TupleTableSlot that hasn't even
> *got* a physical CTID field.
>
> Instead, the planner arranges for the TID to be carried up as an
> explicit resjunk column named ctid. (Currently this is done in
> rewriteTargetListUD(), but see also preptlist.c which does some
related
> things for SELECT FOR UPDATE.)
>
> I'm inclined to think that what we need here is for FDWs to be able to
> modify the details of that behavior, at least to the extent of being
> able to specify a different data type than TID for the row
> identification column.
Would that imply inventing a new system attribute for
"foreign tid"?
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-09-13 14:09:20 | Re: [v9.3] writable foreign tables |
Previous Message | Simon Riggs | 2012-09-13 13:29:08 | Re: remove dead ports? |