foreign tables imported
       from a foreign server. The default is <literal>true</literal>.  You might
       need to turn this off if the remote server has a different set of
       collation names than the local server does, which is likely to be the
       case if it's running on a different operating system.
       If you do so, however, there is a very severe risk that the imported
       table columns' collations will not match the underlying data, resulting
       in anomalous query behavior.
      </para>

      <para>
       Even when this parameter is set to <literal>true</literal>, importing
       columns whose collation is the remote server's default can be risky.
       They will be imported with <literal>COLLATE "default"</literal>, which
       will select the local server's default collation, which could be
       different.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><literal>import_default</literal> (<type>boolean</type>)</term>
     <listitem>
      <para>
       This option controls whether column <literal>DEFAULT</literal> expressions
       are included in the definitions of foreign tables imported
       from a foreign server. The default is <literal>false</literal>.  If you
       enable this option, be wary of defaults that might get computed
       differently on the local server than they would be on the remote
       server; <function>nextval()</function> is a common source of problems.
       The <command>IMPORT</command> will fail altogether if an imported default
       expression uses a function or operator that does not exist locally.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><literal>import_generated</literal> (<type>boolean</type>)</term>
     <listitem>
      <para>
       This option controls whether column <literal>GENERATED</literal> expressions
       are included in the definitions of foreign tables imported
       from a foreign server. The default is <literal>true</literal>.
       The <command>IMPORT</command> will fail altogether if an imported generated
       expression uses a function or operator that does not exist locally.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term><literal>import_not_null</literal> (<type>boolean</type>)</term>
     <listitem>
      <para>
       This option controls whether column <literal>NOT NULL</literal>
       constraints are included in the definitions of foreign tables imported
       from a foreign server. The default is <literal>true</literal>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   <para>
    Note that constraints other than <literal>NOT NULL</literal> will never be
    imported from the remote tables.  Although <productname>PostgreSQL</productname>
    does support check constraints on foreign tables, there is no
    provision for importing them automatically, because of the risk that a
    constraint expression could evaluate differently on the local and remote
    servers.  Any such inconsistency in the behavior of a check
    constraint could lead to hard-to-detect errors in query optimization.
    So if you wish to import check constraints, you must do so
    manually, and you should verify the semantics of each one carefully.
    For more detail about the treatment of check constraints on
    foreign tables, see <xref linkend="sql-createforeigntable"/>.
   </para>

   <para>
    Tables or foreign tables which are partitions of some other table are
    imported only when they are explicitly specified in
    <literal>LIMIT TO</literal> clause.  Otherwise they are automatically
    excluded from <xref linkend="sql-importforeignschema"/>.
    Since all data can be accessed through the partitioned table
    which is the root of the partitioning hierarchy, importing only
    partitioned tables should allow access to all the data without
    creating extra objects.
   </para>

  </sect3>

  <sect3 id="postgres-fdw-options-connection-management">