From: Robert Haas <rhaas@postgresql.org>
Date: Tue, 21 Apr 2015 21:46:47 +0000 (-0400)
Subject: Update FDW docs to reflect existence of CHECK constraints.
X-Git-Tag: REL9_5_ALPHA1~421
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0275ecf31cda9329ee822a6a806a2018144520ed;p=postgresql

Update FDW docs to reflect existence of CHECK constraints.

Generalize the remarks previously made about NOT NULL constraints to
CHECK constraints.

Etsuro Fujita
---

diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index c1daa4be5a..5af41318e5 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -242,13 +242,13 @@ IterateForeignScan (ForeignScanState *node);
 
     <para>
      Note that <productname>PostgreSQL</productname>'s executor doesn't care
-     whether the rows returned violate any <literal>NOT NULL</literal>
-     constraints that were defined on the foreign table columns &mdash; but
-     the planner does care, and may optimize queries incorrectly if
-     <literal>NULL</> values are present in a column declared not to contain
-     them.  If a <literal>NULL</> value is encountered when the user has
-     declared that none should be present, it may be appropriate to raise an
-     error (just as you would need to do in the case of a data type mismatch).
+     whether the rows returned violate any constraints that were defined on
+     the foreign table &mdash; but the planner does care, and may optimize
+     queries incorrectly if there are rows visible in the foreign table that
+     do not satisfy a declared constraint.  If a constraint is violated when
+     the user has declared that the constraint should hold true, it may be
+     appropriate to raise an error (just as you would need to do in the case
+     of a data type mismatch).
     </para>
 
     <para>