row-by-row approach is necessary, but it can be inefficient. If it is

possible for the foreign server to determine which rows should be

modified without actually retrieving them, and if there are no local

triggers which would affect the operation, then it is possible to

arrange things so that the entire operation is performed on the remote

server. The interfaces described below make this possible.

structures which would affect the operation (row-level local triggers,

stored generated columns, or <literal>WITH CHECK OPTION</literal>

constraints from parent views), then it is possible to arrange things

so that the entire operation is performed on the remote server. The

interfaces described below make this possible.

</para>

<para>

sending the whole query to the remote server if there are no query

<literal>WHERE</literal> clauses that cannot be sent to the remote server,

no local joins for the query, no row-level local <literal>BEFORE</literal> or

<literal>AFTER</literal> triggerson the target table, and no

<literal>CHECK OPTION</literal> constraints from parent views.

In <command>UPDATE</command>,

<literal>AFTER</literal> triggersor stored generated columns on the target

table, and no<literal>CHECK OPTION</literal> constraints from parent

views.In <command>UPDATE</command>,

expressions to assign to target columns must use only built-in data types,

<literal>IMMUTABLE</literal> operators, or <literal>IMMUTABLE</literal> functions,

to reduce the risk of misexecution of the query.