for queries
   generated by <filename>postgres_fdw</filename> itself, because it always
   supplies such qualification.  However, this can pose a hazard for
   functions that are executed on the remote server via triggers or rules
   on remote tables.  For example, if a remote table is actually a view,
   any functions used in that view will be executed with the restricted
   search path.  It is recommended to schema-qualify all names in such
   functions, or else attach <literal>SET search_path</literal> options
   (see <xref linkend="sql-createfunction"/>) to such functions
   to establish their expected search path environment.
  </para>

  <para>
   <filename>postgres_fdw</filename> likewise establishes remote session settings
   for various parameters:
   <itemizedlist spacing="compact">
    <listitem>
     <para>
      <xref linkend="guc-timezone"/> is set to <literal>UTC</literal>
     </para>
    </listitem>
    <listitem>
     <para>
      <xref linkend="guc-datestyle"/> is set to <literal>ISO</literal>
     </para>
    </listitem>
    <listitem>
     <para>
      <xref linkend="guc-intervalstyle"/> is set to <literal>postgres</literal>
     </para>
    </listitem>
    <listitem>
     <para>
      <xref linkend="guc-extra-float-digits"/> is set to <literal>3</literal> for remote
      servers 9.0 and newer and is set to <literal>2</literal> for older versions
     </para>
    </listitem>
   </itemizedlist>
   These are less likely to be problematic than <varname>search_path</varname>, but
   can be handled with function <literal>SET</literal> options if the need arises.
  </para>

  <para>
   It is <emphasis>not</emphasis> recommended that you override this behavior by
   changing the session-level settings of these parameters; that is likely
   to cause <filename>postgres_fdw</filename> to malfunction.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-cross-version-compatibility">
  <title>Cross-Version Compatibility</title>

  <para>
   <filename>postgres_fdw</filename> can be used with remote servers dating back
   to <productname>PostgreSQL</productname> 8.3.  Read-only capability is available
   back to 8.1.
  </para>
  <para>
   A limitation however is that <filename>postgres_fdw</filename>
   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</literal> 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</quote> 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</literal> with <literal>OFFSET 0</literal> as an
   optimization fence, and placing the problematic function or operator
   outside the sub-<literal>SELECT</literal>.
  </para>
  <para>
   Another limitation is that when executing <command>INSERT</command>
   statements with an <literal>ON CONFLICT DO NOTHING</literal> clause on
   a foreign table, the remote server must be running
   <productname>PostgreSQL</productname> 9.5 or later,
   as earlier versions do not support this feature.
  </para>
 </sect2>

 <sect2 id="postgres-fdw-wait-events">
  <title>Wait Events</title>

  <para>
   <filename>postgres_fdw</filename> can report the following wait events
   under the wait event type <literal>Extension</literal>:
  </para>

  <variablelist>
   <varlistentry>
    <term><literal>PostgresFdwCleanupResult</literal></term>
    <listitem>
     <para>
      Waiting for transaction abort on remote server.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>PostgresFdwConnect</literal></term>
    <listitem>
     <para>
      Waiting to establish a connection to a remote server.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>PostgresFdwGetResult</literal></term>