Document cross-version compatibility issues for contrib/postgres_fdw.

One of the use-cases for postgres_fdw is extracting data from older PG
servers, so cross-version compatibility is important.  Document what we
can do here, and further annotate some of the coding choices that create
compatibility constraints.  In passing, remove one unnecessary
incompatibility with old servers, namely assuming that we didn't need to
quote the timezone name 'UTC'.

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/src/sgml/postgres-fdw.sgml b/doc/src/sgml/postgres-fdw.sgml
index 61cc2aafc24..4aa798ac2ee 100644
--- a/doc/src/sgml/postgres-fdw.sgml
+++ b/doc/src/sgml/postgres-fdw.sgml
@@ -319,6 +319,26 @@
  </sect2>
 
  <sect2>
+  <title>Cross-Version Compatibility</title>
+
+  <para>
+   <filename>postgres_fdw</> can be used with remote servers dating back
+   to <productname>PostgreSQL</> 8.3.  Read-only capability is available
+   back to 8.1.  A limitation however is that <filename>postgres_fdw</>
+   generally assumes that immutable built-in functions and operators are
+   safe to send to the remote server for execution, if they appear in a
+   <literal>WHERE</> clause for a foreign table.  Thus, a built-in
+   function that was added since the remote server's release might be sent
+   to it for execution, resulting in <quote>function does not exist</> or
+   a similar error.  This type of failure can be worked around by
+   rewriting the query, for example by embedding the foreign table
+   reference in a sub-<literal>SELECT</> with <literal>OFFSET 0</> as an
+   optimization fence, and placing the problematic function or operator
+   outside the sub-<literal>SELECT</>.
+  </para>
+ </sect2>
+
+ <sect2>
   <title>Author</title>
   <para>
    Shigeru Hanada <email>shigeru.hanada@gmail.com</email>