<type>integer</type> value <literal>1</literal> can be cast implicitly to
<type>numeric</type>, so that type is used.
</para>
</example>

<example>
<title>Type Resolution in a Transposed Union</title>

<para>
<screen>
SELECT 1 AS "real" UNION SELECT CAST('2.2' AS REAL);

 real
------
    1
  2.2
(2 rows)
</screen>
Here, since type <type>real</type> cannot be implicitly cast to <type>integer</type>,
but <type>integer</type> can be implicitly cast to <type>real</type>, the union
result type is resolved as <type>real</type>.
</para>
</example>

<example>
<title>Type Resolution in a Nested Union</title>

<para>
<screen>
SELECT NULL UNION SELECT NULL UNION SELECT 1;

ERROR:  UNION types text and integer cannot be matched
</screen>
This failure occurs because <productname>PostgreSQL</productname> treats
multiple <literal>UNION</literal>s as a nest of pairwise operations;
that is, this input is the same as
<screen>
(SELECT NULL UNION SELECT NULL) UNION SELECT 1;
</screen>
The inner <literal>UNION</literal> is resolved as emitting
type <type>text</type>, according to the rules given above.  Then the
outer <literal>UNION</literal> has inputs of types <type>text</type>
and <type>integer</type>, leading to the observed error.  The problem
can be fixed by ensuring that the leftmost <literal>UNION</literal>
has at least one input of the desired result type.
</para>

<para>
<literal>INTERSECT</literal> and <literal>EXCEPT</literal> operations are
likewise resolved pairwise.  However, the other constructs described in this
section consider all of their inputs in one resolution step.
</para>
</example>
</sect1>

<sect1 id="typeconv-select">
<title><literal>SELECT</literal> Output Columns</title>

<indexterm zone="typeconv-select">
 <primary>SELECT</primary>
 <secondary>determination of result type</secondary>
</indexterm>

<para>
The rules given in the preceding sections will result in assignment
of non-<type>unknown</type> data types to all expressions in an SQL query,
except for unspecified-type literals that appear as simple output
columns of a <command>SELECT</command> command.  For example, in

<screen>
SELECT 'Hello World';
</screen>

there is nothing to identify what type the string literal should be
taken as.  In this situation <productname>PostgreSQL</productname> will fall back
to resolving the literal's type as <type>text</type>.
</para>

<para>
When the <command>SELECT</command> is one arm of a <literal>UNION</literal>
(or <literal>INTERSECT</literal> or <literal>EXCEPT</literal>) construct, or when it
appears within <command>INSERT ... SELECT</command>, this rule is not applied
since rules given in preceding sections take precedence.  The type of an
unspecified-type literal can be taken from the other <literal>UNION</literal> arm
in the first case, or from the destination column in the second case.
</para>

<para>
<literal>RETURNING</literal> lists are treated the same as <command>SELECT</command>
output lists for this purpose.
</para>

<note>
 <para>
  Prior to <productname>PostgreSQL</productname> 10, this rule did not exist, and
  unspecified-type literals in a <command>SELECT</command> output list were
  left as type <type>unknown</type>.  That had assorted bad consequences,
  so it's been changed.
 </para>
</note>

</sect1>
</chapter>