aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobert Haas <rhaas@postgresql.org>2011-06-13 08:28:41 -0400
committerRobert Haas <rhaas@postgresql.org>2011-06-13 08:29:38 -0400
commit43ea23a346cd32d5ae2ca1d465db6f3beb65bf13 (patch)
treea3da1ff392fd5065f3359c990559c0cbee3e4f80
parent13000b44d6069743db98ec753763d882b9a0beaf (diff)
downloadpostgresql-43ea23a346cd32d5ae2ca1d465db6f3beb65bf13.tar.gz
postgresql-43ea23a346cd32d5ae2ca1d465db6f3beb65bf13.zip
More foreign table documentation improvements.
Shigeru Hanada, with some additional wordsmithing by me
-rw-r--r--doc/src/sgml/ddl.sgml9
-rw-r--r--doc/src/sgml/fdwhandler.sgml11
2 files changed, 16 insertions, 4 deletions
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 9709dd613ff..09d7a24a25c 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -3021,10 +3021,11 @@ ANALYZE measurement;
<firstterm>foreign data wrapper</firstterm>. A foreign data wrapper is a
library that can communicate with an external data source, hiding the
details of connecting to the data source and fetching data from it. There
- are several foreign data wrappers available, which can for example read
- plain data files residing on the server, or connect to another PostgreSQL
- instance. If none of the existing foreign data wrappers suit your needs,
- you can write your own; see <xref linkend="fdwhandler">.
+ is a foreign data wrapper available as a <file>contrib</file> module,
+ which can read plain data files residing on the server. Other kind of
+ foreign data wrappers might be found as third party products. If none of
+ the existing foreign data wrappers suit your needs, you can write your
+ own; see <xref linkend="fdwhandler">.
</para>
<para>
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index fc07f129b79..c8ae861852a 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -180,6 +180,17 @@ IterateForeignScan (ForeignScanState *node);
</para>
<para>
+ Note that <productname>PostgreSQL</productname>'s executor doesn't care
+ whether the rows returned violate the <literal>NOT NULL</literal>
+ constraints which were defined on the foreign table columns - 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).
+ </para>
+
+ <para>
<programlisting>
void
ReScanForeignScan (ForeignScanState *node);