Re: [v9.3] writable foreign tables

2013/3/3 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>> On 02/08/2013 01:03 AM, Kohei KaiGai wrote:
>>> The attached patch adds Daniel's reworks on make_modifytable
>>> invocation, and add a short comment on add_base_rels_to_query(). Rest
>>> of portion has not been changed from the previous version.
>
>> How's this looking for 9.3? On-list discussion seems to have been
>> positive but inconclusive and time's running out. Do you think this can
>> be turned into a production-worthy feature in the next week or two?
>
> I think it needs major changes. The portion against
> contrib/postgres_fdw fails to apply at all, of course, but that's my
> fault for having hacked so much on postgres_fdw before committing it.
> More generally, I don't much like the approach to ctid-substitute
> columns --- I think hacking on the rel's tupledesc like that is
> guaranteed to break things all over the place. The assorted ugly
> kluges that are already in the patch because of it are just scratching
> the surface, and there may well be consequences that are flat out
> unfixable. Probably the resjunk-columns mechanism would offer a better
> solution.
>
Probably, the latest patch takes an approach that utilizes resjunk-columns
that moves remote row-identifier on scan stage to modify stage, but no
hacks on tupledesc.
The new GetForeignRelWidth API allows FDW drivers to append slots
to return a few pseudo-columns to upper level scan. It can contain
a remote row-identifier of the row to be modified.
Also, rewriteTargetListUD() injects a junk target-entry to reference this
pseudo-column on update or delete from foreign tables as regular
table is doing on ctid.

Regarding to the portion towards postgres_fdw, I'm under reworking
on the part-2 of this patch to apply cleanly.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>