Use <literal>DROP ... IF EXISTS</literal> commands to drop objects
        in <option>--clean</option> mode.  This suppresses <quote>does not
        exist</quote> errors that might otherwise be reported.  This
        option is not valid unless <option>--clean</option> is also
        specified.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--include-foreign-data=<replaceable class="parameter">foreignserver</replaceable></option></term>
      <listitem>
       <para>
        Dump the data for any foreign table with a foreign server
        matching <replaceable class="parameter">foreignserver</replaceable>
        pattern. Multiple foreign servers can be selected by writing multiple
        <option>--include-foreign-data</option> switches.
        Also, the <replaceable class="parameter">foreignserver</replaceable> parameter is
        interpreted as a pattern according to the same rules used by
        <application>psql</application>'s <literal>\d</literal> commands
        (see <xref linkend="app-psql-patterns"/>),
        so multiple foreign servers can also be selected by writing wildcard characters
        in the pattern.  When using wildcards, be careful to quote the pattern
        if needed to prevent the shell from expanding the wildcards; see
        <xref linkend="pg-dump-examples"/> below.
        The only exception is that an empty pattern is disallowed.
       </para>

       <note>
        <para>
         Using wildcards in <option>--include-foreign-data</option> may result
         in access to unexpected foreign servers. Also, to use this option securely,
         make sure that the named server must have a trusted owner.
        </para>
       </note>

       <note>
        <para>
         When <option>--include-foreign-data</option> is specified,
         <application>pg_dump</application> does not check that the foreign
         table is writable.  Therefore, there is no guarantee that the
         results of a foreign table dump can be successfully restored.
        </para>
       </note>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--inserts</option></term>
      <listitem>
       <para>
        Dump data as <command>INSERT</command> commands (rather
        than <command>COPY</command>).  This will make restoration very slow;
        it is mainly useful for making dumps that can be loaded into
        non-<productname>PostgreSQL</productname> databases.
        Any error during restoring will cause only rows that are part of the
        problematic <command>INSERT</command> to be lost, rather than the
        entire table contents.  Note that the restore might fail altogether if
        you have rearranged column order.  The
        <option>--column-inserts</option> option is safe against column order
        changes, though even slower.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--load-via-partition-root</option></term>
      <listitem>
       <para>
        When dumping data for a table partition, make
        the <command>COPY</command> or <command>INSERT</command> statements
        target the root of the partitioning hierarchy that contains it, rather
        than the partition itself.  This causes the appropriate partition to
        be re-determined for each row when the data is loaded.  This may be
        useful when restoring data on a server where rows do not always fall
        into the same partitions as they did on the original server.  That
        could happen, for example, if the partitioning column is of type text
        and the two systems have different definitions of the collation used
        to sort the partitioning column.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--lock-wait-timeout=<replaceable class="parameter">timeout</replaceable></option></term>
      <listitem>
       <para>
        Do