as if the array parameter were replaced by one or more occurrences
of its element type, as needed to match the call.  After such expansion the
function might have effective argument types identical to some non-variadic
function.  In that case the function appearing earlier in the search path is
used, or if the two functions are in the same schema, the non-variadic one is
preferred.
</para>
<para>
This creates a security hazard when calling, via qualified name
  <footnote id="func-qualified-security">
   <!-- If you edit this, consider editing op-qualified-security. -->
   <para>
    The hazard does not arise with a non-schema-qualified name, because a
    search path containing schemas that permit untrusted users to create
    objects is not a <link linkend="ddl-schemas-patterns">secure schema usage
    pattern</link>.
   </para>
  </footnote>,
a variadic function found in a schema that permits untrusted users to create
objects.  A malicious user can take control and execute arbitrary SQL
functions as though you executed them.  Substitute a call bearing
the <literal>VARIADIC</literal> keyword, which bypasses this hazard.  Calls
populating <literal>VARIADIC "any"</literal> parameters often have no
equivalent formulation containing the <literal>VARIADIC</literal> keyword.  To
issue those calls safely, the function's schema must permit only trusted users
to create objects.
</para>
</step>
<step performance="optional">
<para>
Functions that have default values for parameters are considered to match any
call that omits zero or more of the defaultable parameter positions.  If more
than one such function matches a call, the one appearing earliest in the
search path is used.  If there are two or more such functions in the same
schema with identical parameter types in the non-defaulted positions (which is
possible if they have different sets of defaultable parameters), the system
will not be able to determine which to prefer, and so an <quote>ambiguous
function call</quote> error will result if no better match to the call can be
found.
</para>
<para>
This creates an availability hazard when calling, via qualified
name<footnoteref linkend="func-qualified-security"/>, any function found in a
schema that permits untrusted users to create objects.  A malicious user can
create a function with the name of an existing function, replicating that
function's parameters and appending novel parameters having default values.
This precludes new calls to the original function.  To forestall this hazard,
place functions in schemas that permit only trusted users to create objects.
</para>
</step>
</substeps>
</step>

<step performance="required">
<para>
Check for a function accepting exactly the input argument types.
If one exists (there can be only one exact match in the set of
functions considered), use it.  Lack of an exact match creates a security
hazard when calling, via qualified
name<footnoteref linkend="func-qualified-security"/>, a function found in a
schema that permits untrusted users to create objects.  In such situations,
cast arguments to force an exact match.  (Cases involving <type>unknown</type>
will never find a match at this step.)
</para>
</step>

<step performance="required">
<para>
If no exact match is found, see if the function call appears
to be a special type conversion request.  This happens if the function call
has just one argument and the function name is the same as the (internal)
name of some data type.  Furthermore, the function argument must be either
an unknown-type literal, or a type that is binary-coercible to the named
data type, or a type that could be converted to the named data type by
applying that type's I/O functions (that is, the conversion is either to or
from one of the standard string types).  When these conditions are met,
the function call is treated as a form of <literal>CAST</literal> specification.
  <footnote>
   <para>
    The reason for this step is to support function-style cast specifications