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">
    <title>Connection Management Options</title>

    <para>
     By default, all connections that <filename>postgres_fdw</filename>
     establishes to foreign servers are kept open in the local session
     for re-use.
    </para>

    <variablelist>

     <varlistentry id="postgres-fdw-option-keep-connections">
      <term><literal>keep_connections</literal> (<type>boolean</type>)</term>
      <listitem>
       <para>
        This option controls whether <filename>postgres_fdw</filename> keeps
        the connections to the foreign server open so that subsequent
        queries can re-use them. It can only be specified for a foreign server.
        The default is <literal>on</literal>. If set to <literal>off</literal>,
        all connections to this foreign server will be discarded at the end of
        each transaction.
      </para>
      </listitem>
     </varlistentry>

     <varlistentry id="postgres-fdw-option-use-scram-passthrough">
      <term><literal>use_scram_passthrough</literal> (<type>boolean</type>)</term>
      <listitem>
       <para>
        This option controls whether <filename>postgres_fdw</filename> will
        use the SCRAM pass-through authentication to connect to the foreign
        server.  With SCRAM pass-through authentication,
        <filename>postgres_fdw</filename> uses SCRAM-hashed secrets instead of
        plain-text user passwords to connect to the remote server.  This
        avoids storing plain-text user passwords in PostgreSQL system
        catalogs.
       </para>

       <para>
        To use SCRAM pass-through authentication:
        <itemizedlist>
         <listitem>
          <para>
           The remote server must request the <literal>scram-sha-256</literal>
           authentication method; otherwise, the connection will fail.
          </para>
         </listitem>

         <listitem>
          <para>
           The remote server can be of any PostgreSQL version that supports
           SCRAM.  Support for <literal>use_scram_passthrough</literal> is
           only required on the client side (FDW side).
          </para>
         </listitem>

         <listitem>
          <para>
           The user mapping password is not used.
          </para>
         </listitem>

         <listitem>
          <para>
           The server running <filename>postgres_fdw</filename> and the remote
           server must have identical SCRAM secrets (encrypted passwords) for
           the user being used on <filename>postgres_fdw</filename> to
           authenticate on the foreign server (same salt and iterations, not
           merely the same password).
          </para>

          <para>
           As a corollary, if FDW connections to multiple hosts are to be
           made, for example for partitioned foreign tables/sharding, then all
           hosts must have identical SCRAM secrets for the users involved.
          </para>
         </listitem>

         <listitem>
          <para>
           The current