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>

<para>
If the string is declared to be of type <type>varchar</type>, as might be the case
if it comes from a table, then the parser will try to convert it to become <type>text</type>:
<screen>
SELECT substr(varchar '1234', 3);

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

This is transformed by the parser to effectively become:
<screen>
SELECT substr(CAST (varchar '1234' AS text), 3);
</screen>
</para>
<para>
<note>
<para>
The parser learns from the <structname>pg_cast</structname> catalog that
<type>text</type> and <type>varchar</type>
are binary-compatible, meaning that one can be passed to a function that
accepts the other without doing any physical conversion.  Therefore, no
type conversion call is really inserted in this case.
</para>
</note>
</para>

<para>
And, if the function is called with an argument of type <type>integer</type>,
the parser will try to convert that to <type>text</type>:
<screen>
SELECT substr(1234, 3);
ERROR:  function substr(integer, integer) does not exist
HINT:  No function matches the given name and argument types. You might need
to add explicit type casts.
</screen>

This does not work because <type>integer</type> does not have an implicit cast
to <type>text</type>.  An explicit cast will work, however:
<screen>
SELECT substr(CAST (1234 AS text), 3);

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

</sect1>

<sect1 id="typeconv-query">
<title>Value Storage</title>

  <para>
   Values to be inserted into a table are converted to the destination
   column's data type according to the
   following steps.
  </para>

<procedure>
<title>Value Storage Type Conversion</title>

<step performance="required">
<para>
Check for an exact match with the target.
</para>
</step>

<step performance="required">
<para>
Otherwise, try to convert the expression to the target type.  This is possible
if an <firstterm>assignment cast</firstterm> between the two types is registered in the
<structname>pg_cast</structname> catalog (see <xref linkend="sql-createcast"/>).
Alternatively, if the expression is an unknown-type literal, the contents of
the literal string will be fed to the input conversion routine for the target
type.
</para>
</step>

<step performance="required">
<para>
Check to see if there is a sizing cast for the target type.  A sizing
cast is a cast from that type to itself.  If one is found in the
<structname>pg_cast</structname> catalog, apply it to the expression before storing
into the destination column.  The implementation function for such a cast
always takes an extra parameter of type <type>integer</type>, which receives
the destination column's <structfield>atttypmod</structfield> value (typically its
declared length, although the interpretation of <structfield>atttypmod</structfield>
varies for different data types), and it may take a third <type>boolean</type>
parameter that says whether the cast is explicit or implicit.  The cast
function
is responsible for applying any length-dependent semantics such