*** 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