to select operators applying to the
domain's base type.  As an example consider
<screen>
CREATE DOMAIN mytext AS text CHECK(...);
CREATE FUNCTION mytext_eq_text (mytext, text) RETURNS boolean AS ...;
CREATE OPERATOR = (procedure=mytext_eq_text, leftarg=mytext, rightarg=text);
CREATE TABLE mytable (val mytext);

SELECT * FROM mytable WHERE val = 'foo';
</screen>
This query will not use the custom operator.  The parser will first see if
there is a <type>mytext</type> <literal>=</literal> <type>mytext</type> operator
(<xref linkend="op-resol-exact-unknown"/>), which there is not;
then it will consider the domain's base type <type>text</type>, and see if
there is a <type>text</type> <literal>=</literal> <type>text</type> operator
(<xref linkend="op-resol-exact-domain"/>), which there is;
so it resolves the <type>unknown</type>-type literal as <type>text</type> and
uses the <type>text</type> <literal>=</literal> <type>text</type> operator.
The only way to get the custom operator to be used is to explicitly cast
the literal:
<screen>
SELECT * FROM mytable WHERE val = text 'foo';
</screen>
so that the <type>mytext</type> <literal>=</literal> <type>text</type> operator is found
immediately according to the exact-match rule.  If the best-match rules
are reached, they actively discriminate against operators on domain types.
If they did not, such an operator would create too many ambiguous-operator
failures, because the casting rules always consider a domain as castable
to or from its base type, and so the domain operator would be considered
usable in all the same cases as a similarly-named operator on the base type.
</para>
</example>

</sect1>

<sect1 id="typeconv-func">
<title>Functions</title>

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

  <para>
   The specific function that is referenced by a function call
   is determined using the following procedure.
  </para>

<procedure>
<title>Function Type Resolution</title>

<step performance="required">
<para>
Select the functions to be considered from the
<classname>pg_proc</classname> system catalog.  If a non-schema-qualified
function name was used, the functions
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 function name was given, only functions in the specified
schema are considered.
</para>

<substeps>
<step performance="optional">
<para>
If the search path finds multiple functions of identical argument types,
only the one appearing earliest in the path is considered.  Functions of
different argument types are considered on an equal footing regardless of
search path position.
</para>
</step>
<step performance="optional">
<para>
If a function is declared with a <literal>VARIADIC</literal> array parameter, and
the call does not use the <literal>VARIADIC</literal> keyword, then the function
is treated 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