diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml
index 5d0dcf5..4b9d7dd 100644
--- a/doc/src/sgml/ref/create_foreign_table.sgml
+++ b/doc/src/sgml/ref/create_foreign_table.sgml
@@ -279,34 +279,33 @@ CHECK ( <replaceable class="PARAMETER">expression</replaceable> ) [ NO INHERIT ]
   <title>Notes</title>
 
    <para>
-    Constraints on foreign tables (such as <literal>CHECK</>
-    or <literal>NOT NULL</> clauses) are not enforced by the
-    core <productname>PostgreSQL</> system, and most foreign data wrappers
-    do not attempt to enforce them either; that is, the constraint is
-    simply assumed to hold true.  There would be little point in such
-    enforcement since it would only apply to rows inserted or updated via
-    the foreign table, and not to rows modified by other means, such as
-    directly on the remote server.  Instead, a constraint attached to a
-    foreign table should represent a constraint that is being enforced by
-    the remote server.
+    Constraints and partition bounds on foreign tables (such as
+    <literal>CHECK</> or <literal>NOT NULL</> clauses) are not enforced by the
+    core <productname>PostgreSQL</> system, and most foreign data wrappers do
+    not attempt to enforce them either; that is, the they is simply assumed to
+    hold true.  There would be little point in such enforcement since it would
+    only apply to rows inserted or updated via the foreign table, and not to
+    rows modified by other means, such as directly on the remote server.
+    Instead, a constraint or partition bounds attached to a foreign table
+    should represent a constraint that is being enforced by the remote server.
    </para>
 
    <para>
     Some special-purpose foreign data wrappers might be the only access
     mechanism for the data they access, and in that case it might be
-    appropriate for the foreign data wrapper itself to perform constraint
-    enforcement.  But you should not assume that a wrapper does that
-    unless its documentation says so.
+    appropriate for the foreign data wrapper itself to perform constraint or
+    partition bound enforcement.  But you should not assume that a wrapper does
+    that unless its documentation says so.
    </para>
 
    <para>
-    Although <productname>PostgreSQL</> does not attempt to enforce
-    constraints on foreign tables, it does assume that they are correct
-    for purposes of query optimization.  If there are rows visible in the
-    foreign table that do not satisfy a declared constraint, queries on
-    the table might produce incorrect answers.  It is the user's
-    responsibility to ensure that the constraint definition matches
-    reality.
+    Although <productname>PostgreSQL</> does not attempt to enforce partition
+    bounds or constraints on foreign tables, it does assume that they are
+    correct for purposes of query optimization.  If there are rows visible in
+    the foreign table that do not satisfy a declared constraint or partition
+    bounds, queries on the table might produce incorrect answers.  It is the
+    user's responsibility to ensure that the constraint definition or partition
+    bound matches reality.
    </para>
  </refsect1>