2013/3/3 Tom Lane <t...@sss.pgh.pa.us>: > Craig Ringer <cr...@2ndquadrant.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers