procedure
   to replace it (this includes being a member of the owning role).
  </para>

  <para>
   The user that creates the procedure becomes the owner of the procedure.
  </para>

  <para>
   To be able to create a procedure, you must have <literal>USAGE</literal>
   privilege on the argument types.
  </para>

  <para>
   Refer to <xref linkend="xproc"/> for further information on writing
   procedures.
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

   <variablelist>
    <varlistentry>
     <term><replaceable class="parameter">name</replaceable></term>

     <listitem>
      <para>
       The name (optionally schema-qualified) of the procedure to create.
      </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.
      </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. The argument types can be base, composite,
       or domain types, or can reference the type of a table column.
      </para>
      <para>
       Depending on the implementation language it might also be allowed
       to specify <quote>pseudo-types</quote> such as <type>cstring</type>.
       Pseudo-types indicate that the actual argument type is either
       incompletely specified, or outside the set of ordinary SQL data types.
      </para>
      <para>
       The type of a column is referenced by writing
       <literal><replaceable
       class="parameter">table_name</replaceable>.<replaceable
       class="parameter">column_name</replaceable>%TYPE</literal>.
       Using this feature can sometimes help make a procedure independent of
       changes to the definition of a table.
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       An expression to be used as default value if the parameter is
       not specified.  The expression has to be coercible to the
       argument type of the parameter.
       All input parameters following a
       parameter with a default value must have default values as well.
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       The name of the language that the procedure is implemented in.
       It can be <literal>sql</literal>, <literal>c</literal>,
       <literal>internal</literal>, or the name of a user-defined
       procedural language, e.g., <literal>plpgsql</literal>.  The default is
       <literal>sql</literal> if <replaceable
       class="parameter">sql_body</replaceable> is specified.  Enclosing the
       name in single quotes is deprecated and requires matching case.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>TRANSFORM { FOR TYPE <replaceable class="parameter">type_name</replaceable> } [, ... ] }</literal></term>

     <listitem>
      <para>
       Lists which transforms a call to the procedure should apply.  Transforms
       convert between SQL types and language-specific data types;
       see <xref linkend="sql-createtransform"/>.  Procedural language
       implementations usually have hardcoded knowledge of the built-in types,
       so those don't need to be listed