Explain CHECK constraint handling in postgres_fdw's IMPORT FOREIGN SCHEMA.

The existing documentation could easily be misinterpreted, and it failed to
explain the inconsistent-evaluation hazard that deterred us from supporting
automatic importing of check constraints.  Revise it.

Etsuro Fujita, further expanded by me

diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 1079140de285ec7e07b2ad398ffa1903109ee6f9..14b12e37dc6cc9fa78be3c1941c7d423aadbb052 100644 (file)
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -309,8 +309,8 @@
     using .  This command creates
     foreign table definitions on the local server that match tables or
     views present on the remote server.  If the remote tables to be imported
-    have columns of user-defined data types, the local server must have types
-    of the same names.
+    have columns of user-defined data types, the local server must have
+    compatible types of the same names.
    
 
    
@@ -361,9 +361,16 @@
 
    
     Note that constraints other than NOT NULL will never be
-    imported from the remote tables, since PostgreSQL
-    does not support any other type of constraint on a foreign table.
-    Checking other types of constraints is always left to the remote server.
+    imported from the remote tables.  Although PostgreSQL
+    does support CHECK constraints on foreign tables, there is no
+    provision for importing them automatically, because of the risk that a
+    constraint expression could evaluate differently on the local and remote
+    servers.  Any such inconsistency in the behavior of a CHECK
+    constraint could lead to hard-to-detect errors in query optimization.
+    So if you wish to import CHECK constraints, you must do so
+    manually, and you should verify the semantics of each one carefully.
+    For more detail about the treatment of CHECK constraints on
+    foreign tables, see .