mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Doc: Update FDW documentation about direct foreign table modification.

Browse Source 
1. Commit 7086be6e3 should have documented the limitation that the direct
   modification is disabled when WCO constraints are present, but didn't,
   which is definitely my fault.  Update the documentation (Postgres 9.6
   onwards).

2. Commit fc22b6623 should have documented the limitation that the direct
   modification is disabled when generated columns are defined, but
   didn't.  Update the documentation (Postgres 12 onwards).

Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com
This commit is contained in:
Etsuro Fujita 2019-09-18 18:50:00 +09:00
parent 48770492c3
commit f9f2fda796
2 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/fdwhandler.sgml
View File

@ -820,9 +820,11 @@ IsForeignRelUpdatable(Relation rel);
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>

6
doc/src/sgml/postgres-fdw.sgml
View File

@ -504,9 +504,9 @@
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> triggers on the target table, and no
<literal>CHECK OPTION</literal> constraints from parent views.
In <command>UPDATE</command>,
<literal>AFTER</literal> triggers or 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.