*** a/doc/src/sgml/fdwhandler.sgml --- b/doc/src/sgml/fdwhandler.sgml *************** *** 1548,1554 **** GetForeignServerByName(const char *name, bool missing_ok); ! PlanForeignModify and the other callbacks described in 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 --- 1548,1554 ---- ! PlanForeignModify and related callbacks described in 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 *************** *** 1557,1563 **** GetForeignServerByName(const char *name, bool missing_ok); 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 . Keep in mind that a path --- 1557,1565 ---- 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, rather than ! using PlanDirectModify and related callbacks for direct ! modification described in the same section. This approach could also be used to implement remote SELECT FOR UPDATE, rather than using the row locking callbacks described in . Keep in mind that a path