(optionally
      schema-qualified), if any.
      See below for details.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>CASCADE</literal></term>
    <listitem>
     <para>
      Automatically drop objects that depend on the procedure,
      and in turn all objects that depend on those objects
      (see <xref linkend="ddl-depend"/>).
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>RESTRICT</literal></term>
    <listitem>
     <para>
      Refuse to drop the procedure if any objects depend on it.  This
      is the default.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1 id="sql-dropprocedure-notes">
  <title>Notes</title>

  <para>
   If there is only one procedure of the given name, the argument list
   can be omitted.  Omit the parentheses too in this case.
  </para>

  <para>
   In <productname>PostgreSQL</productname>, it's sufficient to list the
   input (including <literal>INOUT</literal>) arguments,
   because no two routines of the same name are allowed to share the same
   input-argument list.  Moreover, the <command>DROP</command> command
   will not actually check that you wrote the types
   of <literal>OUT</literal> arguments correctly; so any arguments that
   are explicitly marked <literal>OUT</literal> are just noise.  But
   writing them is recommendable for consistency with the
   corresponding <command>CREATE</command> command.
  </para>

  <para>
   For compatibility with the SQL standard, it is also allowed to write
   all the argument data types (including those of <literal>OUT</literal>
   arguments) without
   any <replaceable class="parameter">argmode</replaceable> markers.
   When this is done, the types of the procedure's <literal>OUT</literal>
   argument(s) <emphasis>will</emphasis> be verified against the command.
   This provision creates an ambiguity, in that when the argument list
   contains no <replaceable class="parameter">argmode</replaceable>
   markers, it's unclear which rule is intended.
   The <command>DROP</command> command will attempt the lookup both ways,
   and will throw an error if two different procedures are found.
   To avoid the risk of such ambiguity, it's recommendable to
   write <literal>IN</literal> markers explicitly rather than letting