<literal>STDIN</literal>, use <filename>-</filename> as the
        filename.  The <option>--filter</option> option can be specified in
        conjunction with <option>--exclude-database</option> for excluding
        databases, and can also be specified more than once for multiple filter
        files.
       </para>

       <para>
        The file lists one database pattern per row, with the following format:
<synopsis>
exclude database <replaceable class="parameter">PATTERN</replaceable>
</synopsis>
       </para>

       <para>
        Lines starting with <literal>#</literal> are considered comments and
        ignored. Comments can be placed after an object pattern row as well.
        Blank lines are also ignored. See <xref linkend="app-psql-patterns"/>
        for how to perform quoting in patterns.
       </para>

      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--if-exists</option></term>
      <listitem>
       <para>
        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>--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.  Note that
        the restore might fail altogether if you have rearranged column order.
        The <option>--column-inserts</option> option is safer, 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 not wait forever to acquire shared table locks at the beginning of
        the dump. Instead, fail if unable to lock a table within the specified
        <replaceable class="parameter">timeout</replaceable>. The timeout may be
        specified in any of the formats accepted by <command>SET
        statement_timeout</command>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-comments</option></term>
      <listitem>
       <para>
        Do not dump <command>COMMENT</command> commands.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-data</option></term>
      <listitem>
       <para>
        Do not dump data.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-policies</option></term>
      <listitem>
       <para>
        Do not dump row security policies.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-publications</option></term>