</listitem>
     <listitem>
      <para>
       <literal>fallback_application_name</literal> (always set to
       <literal>postgres_fdw</literal>)
      </para>
     </listitem>
     <listitem>
      <para>
       <literal>sslkey</literal> and <literal>sslcert</literal> - these may
       appear in <emphasis>either or both</emphasis> a connection and a user
       mapping. If both are present, the user mapping setting overrides the
       connection setting.
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    Only superusers may create or modify user mappings with the
    <literal>sslcert</literal> or <literal>sslkey</literal> settings.
   </para>
   <para>
    Non-superusers may connect to foreign servers using password
    authentication or with GSSAPI delegated credentials, so specify the
    <literal>password</literal> option for user mappings belonging to
    non-superusers where password authentication is required.
   </para>
   <para>
    A superuser may override this check on a per-user-mapping basis by setting
    the user mapping option <literal>password_required 'false'</literal>, e.g.,
<programlisting>
ALTER USER MAPPING FOR some_non_superuser SERVER loopback_nopw
OPTIONS (ADD password_required 'false');
</programlisting>
    To prevent unprivileged users from exploiting the authentication rights
    of the unix user the postgres server is running as to escalate to superuser
    rights, only the superuser may set this option on a user mapping.
    </para>
    <para>
    Care is required to ensure that this does not allow the mapped
    user the ability to connect as superuser to the mapped database per
    CVE-2007-3278 and CVE-2007-6601. Don't set
    <literal>password_required=false</literal>
    on the <literal>public</literal> role. Keep in mind that the mapped
    user can potentially use any client certificates,
    <filename>.pgpass</filename>,
    <filename>.pg_service.conf</filename> etc. in the unix home directory of the
    system user the postgres server runs as.   (For details on how home
    directories are found, see <xref linkend="libpq-pgpass"/>.)  They can
    also use any trust
    relationship granted by authentication modes like <literal>peer</literal>
    or <literal>ident</literal> authentication.
   </para>
  </sect3>

  <sect3 id="postgres-fdw-options-object-name">
   <title>Object Name Options</title>

   <para>
    These options can be used to control the names used in SQL statements
    sent to the remote <productname>PostgreSQL</productname> server.  These
    options are needed when a foreign table is created with names different
    from the underlying remote table's names.
   </para>

   <variablelist>

    <varlistentry>
     <term><literal>schema_name</literal> (<type>string</type>)</term>
     <listitem>
      <para>
       This option, which can be specified for a foreign table, gives the
       schema name to use for the foreign table on the remote server.  If this
       option is omitted, the name of the foreign table's schema is used.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>table_name</literal> (<type>string</type>)</term>
     <listitem>
      <para>
       This option, which can be specified for a foreign table, gives the
       table name to use for the foreign table on the remote server.  If this
       option is omitted, the foreign table's name is used.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>column_name</literal> (<type>string</type>)</term>
     <listitem>
      <para>
       This option, which can be specified for a column of a foreign table,
       gives the column name to use for the column on the remote server.
       If this option is omitted, the column's name is used.
      </para>
     </listitem>
    </varlistentry>

   </variablelist>

  </sect3>

  <sect3 id="postgres-fdw-options-cost-estimation">
   <title>Cost Estimation Options</title>