Robert Haas <robertmhaas@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
foreignrelation will be scanned in the usual way and then individual row updates will be driven by a local
ModifyTableplan node. This approach is necessary for the general case where an update requires reading local tables as
wellas foreign tables. However, if the operation could be executed entirely by the foreign server, the FDW could
generatea path representing that and insert it into the UPPERREL_FINAL upper relation, where it would compete against
theModifyTable 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
responsiblefor 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
