<firstterm>overloading</firstterm>).
  </para>

  <para>
   To replace the current definition of an existing function, use
   <command>CREATE OR REPLACE FUNCTION</command>.  It is not possible
   to change the name or argument types of a function this way (if you
   tried, you would actually be creating a new, distinct function).
   Also, <command>CREATE OR REPLACE FUNCTION</command> will not let
   you change the return type of an existing function.  To do that,
   you must drop and recreate the function.  (When using <literal>OUT</literal>
   parameters, that means you cannot change the types of any
   <literal>OUT</literal> parameters except by dropping the function.)
  </para>

  <para>
   When <command>CREATE OR REPLACE FUNCTION</command> is used to replace an
   existing function, the ownership and permissions of the function
   do not change.  All other function properties are assigned the
   values specified or implied in the command.  You must own the function
   to replace it (this includes being a member of the owning role).
  </para>

  <para>
   If you drop and then recreate a function, the new function is not
   the same entity as the old; you will have to drop existing rules, views,
   triggers, etc. that refer to the old function.  Use
   <command>CREATE OR REPLACE FUNCTION</command> to change a function
   definition without breaking objects that refer to the function.
   Also, <command>ALTER FUNCTION</command> can be used to change most of the
   auxiliary properties of an existing function.
  </para>

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

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

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

 <refsect1>
  <title>Parameters</title>

   <variablelist>

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

     <listitem>
      <para>
       The name (optionally schema-qualified) of the function 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>.
       Only <literal>OUT</literal> arguments can follow a <literal>VARIADIC</literal> one.
       Also, <literal>OUT</literal> and <literal>INOUT</literal> arguments cannot be used
       together with the <literal>RETURNS TABLE</literal> notation.
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       The name of an argument. Some languages (including SQL and PL/pgSQL)
       let you use the name in the function body.  For other languages the
       name of an input argument is just extra documentation, so far as
       the function itself is concerned; but you can use input argument names
       when calling a function to improve readability (see <xref
       linkend="sql-syntax-calling-funcs"/>).  In any case, the name
       of an output argument is significant, because it defines the column
       name in the result row type.  (If you omit the name for an output
       argument, the system will choose a default column name.)
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       The data type(s) of the function'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>