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

From Tom Lane
Subject Re: [v9.3] writable foreign tables
Date
Msg-id 388.1346165248@sss.pgh.pa.us
Whole thread Raw
In response to Re: [v9.3] writable foreign tables  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.3] writable foreign tables
Re: [v9.3] writable foreign tables
List pgsql-hackers
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
>> 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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Timing overhead and Linux clock sources
Next
From: Tom Lane
Date:
Subject: Re: [v9.3] writable foreign tables