Robert Haas <robertmh...@gmail.com> writes:
> Overall, I think this is looking pretty good.
I hadn't been paying any attention to this thread, but I wonder whether
this entire approach isn't considerably inferior to what we can do now
with the planner pathification patch. To quote from the new docs:
PlanForeignModify and the other callbacks described in Section 54.2.3
are designed around the assumption that the foreign relation will be
scanned in the usual way and then individual row updates will be driven
by a local ModifyTable plan node. This approach is necessary for the
general case where an update requires reading local tables as well as
foreign tables. However, if the operation could be executed entirely by
the foreign server, the FDW could generate a path representing that and
insert it into the UPPERREL_FINAL upper relation, where it would
compete against the ModifyTable approach. This approach could also be
used to implement remote SELECT FOR UPDATE, rather than using the row
locking callbacks described in Section 54.2.4. Keep in mind that a path
inserted into UPPERREL_FINAL is responsible for implementing all
behavior of the query.
I don't really see anything that this patch does that wouldn't be better
done that way. And I'd kind of like to get a working example of that type
of path insertion into 9.6, so that we can find out if we need any hooks
or callbacks that aren't there today.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
