SELECT min($1[i]) FROM generate_subscripts($1, 1) g(i);
$$ LANGUAGE SQL;

SELECT anyleast(10, -1, 5, 4);
 anyleast
----------
       -1
(1 row)

SELECT anyleast('abc'::text, 'def');
 anyleast
----------
 abc
(1 row)

CREATE FUNCTION concat_values(text, VARIADIC anyarray) RETURNS text AS $$
    SELECT array_to_string($2, $1);
$$ LANGUAGE SQL;

SELECT concat_values('|', 1, 4, 2);
 concat_values
---------------
 1|4|2
(1 row)
</screen>
    </para>
   </sect2>

   <sect2 id="xfunc-sql-collations">
    <title><acronym>SQL</acronym> Functions with Collations</title>

    <indexterm>
     <primary>collation</primary>
     <secondary>in SQL functions</secondary>
    </indexterm>

    <para>
     When an SQL function has one or more parameters of collatable data types,
     a collation is identified for each function call depending on the
     collations assigned to the actual arguments, as described in <xref
     linkend="collation"/>.  If a collation is successfully identified
     (i.e., there are no conflicts of implicit collations among the arguments)
     then all the collatable parameters are treated as having that collation
     implicitly.  This will affect the behavior of collation-sensitive
     operations within the function.  For example, using the
     <function>anyleast</function> function described above, the result of
<programlisting>
SELECT anyleast('abc'::text, 'ABC');
</programlisting>
     will depend on the database's default collation.  In <literal>C</literal> locale
     the result will be <literal>ABC</literal>, but in many other locales it will
     be <literal>abc</literal>.  The collation to use can be forced by adding
     a <literal>COLLATE</literal> clause to any of the arguments, for example
<programlisting>
SELECT anyleast('abc'::text, 'ABC' COLLATE "C");
</programlisting>
     Alternatively, if you wish a function to operate with a particular
     collation regardless of what it is called with, insert
     <literal>COLLATE</literal> clauses as needed in the function definition.
     This version of <function>anyleast</function> would always use <literal>en_US</literal>
     locale to compare strings:
<programlisting>
CREATE FUNCTION anyleast (VARIADIC anyarray) RETURNS anyelement AS $$
    SELECT min($1[i] COLLATE "en_US") FROM generate_subscripts($1, 1) g(i);
$$ LANGUAGE SQL;
</programlisting>
     But note that this will throw an error if applied to a non-collatable
     data type.
    </para>

    <para>
     If no common collation can be identified among the actual arguments,
     then an SQL function treats its parameters as having their data types'
     default collation (which is usually the database's default collation,
     but could be different for parameters of domain types).
    </para>

    <para>
     The behavior of collatable parameters can be thought of as a limited
     form of polymorphism, applicable only to textual data types.
    </para>
   </sect2>
  </sect1>

  <sect1 id="xfunc-overload">
   <title>Function Overloading</title>

   <indexterm zone="xfunc-overload">
    <primary>overloading</primary>
    <secondary>functions</secondary>
   </indexterm>

   <para>
    More than one function can be defined with the same SQL name, so long
    as the arguments they take are different.  In other words,
    function names can be <firstterm>overloaded</firstterm>.  Whether or not
    you use it, this capability entails security precautions when calling
    functions in databases where some users mistrust other users; see
    <xref linkend="typeconv-func"/>.  When a query is executed, the server
    will determine which function to call from the data types and the number
    of the provided arguments.  Overloading can also be used to simulate
    functions with a variable number of arguments, up to a finite maximum
    number.
   </para>

   <para>
    When creating a family of overloaded functions, one should be
    careful not to create ambiguities.  For instance, given the
    functions: