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 id="op-resol-last-unknown" 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>
Some examples follow.
</para>

<example>
<title>Square Root Operator Type Resolution</title>

<para>
There is only one square root operator (prefix <literal>|/</literal>)
defined in the standard catalog, and it takes an argument of type
<type>double precision</type>.
The scanner assigns an initial type of <type>integer</type> to the argument
in this query expression:
<screen>
SELECT |/ 40 AS "square root of 40";
 square root of 40
-------------------
 6.324555320336759
(1 row)
</screen>

So the parser does a type conversion on the operand and the query
is equivalent to:

<screen>
SELECT |/ CAST(40 AS double precision) AS "square root of 40";
</screen>
</para>
</example>

<example>
<title>String Concatenation Operator Type Resolution</title>

<para>
A string-like syntax is used for working with string types and for
working with complex extension types.
Strings with unspecified type are matched with likely operator candidates.
</para>

<para>
An example with one unspecified argument:
<screen>
SELECT text 'abc' || 'def' AS "text and unknown";

 text and unknown
------------------
 abcdef
(1 row)
</screen>
</para>

<para>
In this case the parser looks to see if there is an operator taking <type>text</type>
for both arguments. Since there is, it assumes that the second argument should
be interpreted as type <type>text</type>.
</para>

<para>
Here is a concatenation of two values of unspecified types:
<screen>
SELECT 'abc' || 'def' AS "unspecified";

 unspecified
-------------
 abcdef
(1 row)
</screen>
</para>

<para>
In this case there is no initial hint for which type to use, since no types
are specified in the query. So, the parser looks for all candidate operators
and finds that there are candidates accepting both string-category and
bit-string-category inputs.  Since string category is preferred when available,
that category is selected, and then the
preferred type for strings, <type>text</type>, is used as the specific
type to resolve the unknown-type literals as.
</para>
</example>

<example>
<title>Absolute-Value and Negation Operator Type Resolution</title>

<para>
The <productname>PostgreSQL</productname> operator catalog has several
entries for the prefix operator <literal>@</literal>, all of which implement
absolute-value operations for various numeric data types.  One of these
entries is for type <type>float8</type>, which is the preferred type in
the numeric category.  Therefore, <productname>PostgreSQL</productname>
will use that entry when faced with an <type>unknown</type> input:
<screen>
SELECT @ '-4.5' AS "abs";
 abs
-----
 4.5
(1 row)
</screen>
Here the system has implicitly resolved the unknown-type literal as type
<type>float8</type> before applying the chosen operator.  We can verify that
<type>float8</type> and not some other type was used:
<screen>
SELECT @ '-4.5e500' AS "abs";

ERROR:  "-4.5e500" is out of range for type double precision
</screen>
</para>

<para>
On the other hand, the prefix operator <literal>~</literal> (bitwise negation)
is defined only for integer data types, not for <type>float8</type>.  So, if we
try a similar case with <literal>~</literal>,