that role must have <literal>CREATE</literal>
   privilege on the procedure's schema.
   (These restrictions enforce that altering the owner
   doesn't do anything you couldn't do by dropping and recreating the procedure.
   However, a superuser can alter ownership of any procedure anyway.)
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name (optionally schema-qualified) of an existing procedure.  If no
      argument list is specified, the name must be unique in its schema.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argmode</replaceable></term>

    <listitem>
     <para>
      The mode of an argument: <literal>IN</literal>, <literal>OUT</literal>,
      <literal>INOUT</literal>, or <literal>VARIADIC</literal>.  If omitted,
      the default is <literal>IN</literal>.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argname</replaceable></term>

    <listitem>
     <para>
      The name of an argument.
      Note that <command>ALTER PROCEDURE</command> does not actually pay
      any attention to argument names, since only the argument data
      types are used to determine the procedure's identity.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">argtype</replaceable></term>

    <listitem>
     <para>
      The data type(s) of the procedure's arguments (optionally
      schema-qualified), if any.
      See <xref linkend="sql-dropprocedure"/> for the details of how
      the procedure is looked up using the argument data type(s).
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_name</replaceable></term>
    <listitem>
     <para>
      The new name of the procedure.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_owner</replaceable></term>
    <listitem>
     <para>
      The new owner of the procedure.  Note that if the procedure is
      marked <literal>SECURITY DEFINER</literal>, it will subsequently
      execute as the new owner.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">new_schema</replaceable></term>
    <listitem>
     <para>
      The new schema for the procedure.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><replaceable class="parameter">extension_name</replaceable></term>
    <listitem>
     <para>
      This form marks the procedure as dependent on the extension, or no longer
      dependent on the extension if <literal>NO</literal> is specified.
      A procedure that's marked as dependent on an extension is dropped when the
      extension is dropped, even if cascade is not specified.
      A procedure can depend upon multiple extensions, and will be dropped when
      any one of those extensions is dropped.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal><optional> EXTERNAL </optional> SECURITY INVOKER</literal></term>
    <term><literal><optional> EXTERNAL </optional> SECURITY DEFINER</literal></term>

    <listitem>
     <para>
      Change whether the procedure is a security definer or not. The
      key word <literal>EXTERNAL</literal> is ignored for SQL
      conformance. See <xref linkend="sql-createprocedure"/> for more information about
      this capability.
     </para>
    </listitem>
   </varlistentry>

     <varlistentry>
      <term><replaceable>configuration_parameter</replaceable></term>
      <term><replaceable>value</replaceable></term>