careful selection
of preferred types and available implicit casts, it is possible to ensure that
ambiguous expressions (those with multiple candidate parsing solutions) can be
resolved in a useful way.
</para>

<para>
All type conversion rules are designed with several principles in mind:

<itemizedlist>
<listitem>
<para>
Implicit conversions should never have surprising or unpredictable outcomes.
</para>
</listitem>

<listitem>
<para>
There should be no extra overhead in the parser or executor
if a query does not need implicit type conversion.
That is, if a query is well-formed and the types already match, then the query should execute
without spending extra time in the parser and without introducing unnecessary implicit conversion
calls in the query.
</para>
</listitem>

<listitem>
<para>
Additionally, if a query usually requires an implicit conversion for a function, and
if then the user defines a new function with the correct argument types, the parser
should use this new function and no longer do implicit conversion to use the old function.
</para>
</listitem>
</itemizedlist>
</para>

</sect1>

<sect1 id="typeconv-oper">
<title>Operators</title>

<indexterm zone="typeconv-oper">
 <primary>operator</primary>
 <secondary>type resolution in an invocation</secondary>
</indexterm>

  <para>
   The specific operator that is referenced by an operator expression
   is determined using the following procedure.
   Note that this procedure is indirectly affected
   by the precedence of the operators involved, since that will determine
   which sub-expressions are taken to be the inputs of which operators.
   See <xref linkend="sql-precedence"/> for more information.
  </para>

<procedure>
<title>Operator Type Resolution</title>

<step id="op-resol-select" performance="required">
<para>
Select the operators to be considered from the
<classname>pg_operator</classname> system catalog.  If a non-schema-qualified
operator name was used (the usual case), the operators
considered are those with the matching name and argument count that are
visible in the current search path (see <xref linkend="ddl-schemas-path"/>).
If a qualified operator name was given, only operators in the specified
schema are considered.
</para>

<substeps>
<step performance="optional">
<para>
If the search path finds multiple operators with identical argument types,
only the one appearing earliest in the path is considered.  Operators with
different argument types are considered on an equal footing regardless of
search path position.
</para>
</step>
</substeps>
</step>

<step id="op-resol-exact-match" performance="required">
<para>
Check for an operator accepting exactly the input argument types.
If one exists (there can be only one exact match in the set of
operators considered), use it.  Lack of an exact match creates a security
hazard when calling, via qualified name
  <footnote id="op-qualified-security">
   <!-- If you edit this, consider editing func-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>
(not typical), any operator found in a schema that permits untrusted users to
create objects.  In such situations, cast arguments to force an exact match.
</para>

<substeps>
<step id="op-resol-exact-unknown" performance="optional">
<para>
If one argument of a binary operator invocation is of the <type>unknown</type> type,
then assume it is the same type as the other argument for this check.
Invocations involving two <type>unknown</type> inputs, or a prefix operator
with an <type>unknown</type> input, will never find a match at this step.
</para>
</step>
<step id="op-resol-exact-domain" performance="optional">
<para>
If one argument of a binary operator invocation is of the <type>unknown</type>
type and the other is of