remaining candidates accept the same type category,
select that category; otherwise fail because
the correct choice cannot be deduced without more clues.
Now discard candidates that do not accept the selected type category.
Furthermore, if any candidate accepts a preferred type in that category,
discard candidates that accept non-preferred types for that argument.
Keep all candidates if none survive these tests.
If only one candidate remains, use it; else continue to the next step.
</para>
</step>
<step performance="required">
<para>
If there are both <type>unknown</type> and known-type arguments, and all
the known-type arguments have the same type, assume that the
<type>unknown</type> arguments are also of that type, and check which
candidates can accept that type at the <type>unknown</type>-argument
positions.  If exactly one candidate passes this test, use it.
Otherwise, fail.
</para>
</step>
</substeps>
</step>
</procedure>

<para>
Note that the <quote>best match</quote> rules are identical for operator and
function type resolution.
Some examples follow.
</para>

<example>
<title>Rounding Function Argument Type Resolution</title>

<para>
There is only one <function>round</function> function that takes two
arguments; it takes a first argument of type <type>numeric</type> and
a second argument of type <type>integer</type>.
So the following query automatically converts
the first argument of type <type>integer</type> to
<type>numeric</type>:

<screen>
SELECT round(4, 4);

 round
--------
 4.0000
(1 row)
</screen>

That query is actually transformed by the parser to:
<screen>
SELECT round(CAST (4 AS numeric), 4);
</screen>
</para>

<para>
Since numeric constants with decimal points are initially assigned the
type <type>numeric</type>, the following query will require no type
conversion and therefore might be slightly more efficient:
<screen>
SELECT round(4.0, 4);
</screen>
</para>
</example>

<example>
<title>Variadic Function Resolution</title>

<para>
<screen>
CREATE FUNCTION public.variadic_example(VARIADIC numeric[]) RETURNS int
  LANGUAGE sql AS 'SELECT 1';
CREATE FUNCTION
</screen>

This function accepts, but does not require, the VARIADIC keyword.  It
tolerates both integer and numeric arguments:

<screen>
SELECT public.variadic_example(0),
       public.variadic_example(0.0),
       public.variadic_example(VARIADIC array[0.0]);
 variadic_example | variadic_example | variadic_example
------------------+------------------+------------------
                1 |                1 |                1
(1 row)
</screen>

However, the first and second calls will prefer more-specific functions, if
available:

<screen>
CREATE FUNCTION public.variadic_example(numeric) RETURNS int
  LANGUAGE sql AS 'SELECT 2';
CREATE FUNCTION

CREATE FUNCTION public.variadic_example(int) RETURNS int
  LANGUAGE sql AS 'SELECT 3';
CREATE FUNCTION

SELECT public.variadic_example(0),
       public.variadic_example(0.0),
       public.variadic_example(VARIADIC array[0.0]);
 variadic_example | variadic_example | variadic_example
------------------+------------------+------------------
                3 |                2 |                1
(1 row)
</screen>

Given the default configuration and only the first function existing, the
first and second calls are insecure.  Any user could intercept them by
creating the second or third function.  By matching the argument type exactly
and using the <literal>VARIADIC</literal> keyword, the third call is secure.
</para>
</example>

<example>
<title>Substring Function Type Resolution</title>

<para>
There are several <function>substr</function> functions, one of which
takes types <type>text</type> and <type>integer</type>.  If called
with a string constant of unspecified type, the system chooses the
candidate function that accepts an argument of the preferred category
<literal>string</literal> (namely of type <type>text</type>).

<screen>
SELECT substr('1234', 3);

 substr
--------
     34
(1 row)
</screen>
</para>