<literal>CAST(<replaceable>x</replaceable> AS
<replaceable>typename</replaceable>)</literal> or
<replaceable>x</replaceable><literal>::</literal><replaceable>typename</replaceable>
construct.
</para>
<para>
If the cast is marked <literal>AS ASSIGNMENT</literal> then it can be invoked
implicitly when assigning a value to a column of the target data type.
For example, supposing that <literal>foo.f1</literal> is a column of
type <type>text</type>, then:
<programlisting>
INSERT INTO foo (f1) VALUES (42);
</programlisting>
will be allowed if the cast from type <type>integer</type> to type
<type>text</type> is marked <literal>AS ASSIGNMENT</literal>, otherwise not.
(We generally use the term <firstterm>assignment
cast</firstterm> to describe this kind of cast.)
</para>
<para>
If the cast is marked <literal>AS IMPLICIT</literal> then it can be invoked
implicitly in any context, whether assignment or internally in an
expression. (We generally use the term <firstterm>implicit
cast</firstterm> to describe this kind of cast.)
For example, consider this query:
<programlisting>
SELECT 2 + 4.0;
</programlisting>
The parser initially marks the constants as being of type <type>integer</type>
and <type>numeric</type> respectively. There is no <type>integer</type>
<literal>+</literal> <type>numeric</type> operator in the system catalogs,
but there is a <type>numeric</type> <literal>+</literal> <type>numeric</type> operator.
The query will therefore succeed if a cast from <type>integer</type> to
<type>numeric</type> is available and is marked <literal>AS IMPLICIT</literal> —
which in fact it is. The parser will apply the implicit cast and resolve
the query as if it had been written
<programlisting>
SELECT CAST ( 2 AS numeric ) + 4.0;
</programlisting>
</para>
<para>
Now, the catalogs also provide a cast from <type>numeric</type> to
<type>integer</type>. If that cast were marked <literal>AS IMPLICIT</literal> —
which it is not — then the parser would be faced with choosing
between the above interpretation and the alternative of casting the
<type>numeric</type> constant to <type>integer</type> and applying the
<type>integer</type> <literal>+</literal> <type>integer</type> operator. Lacking any
knowledge of which choice to prefer, it would give up and declare the
query ambiguous. The fact that only one of the two casts is
implicit is the way in which we teach the parser to prefer resolution
of a mixed <type>numeric</type>-and-<type>integer</type> expression as
<type>numeric</type>; there is no built-in knowledge about that.
</para>
<para>
It is wise to be conservative about marking casts as implicit. An
overabundance of implicit casting paths can cause
<productname>PostgreSQL</productname> to choose surprising
interpretations of commands, or to be unable to resolve commands at
all because there are multiple possible interpretations. A good
rule of thumb is to make a cast implicitly invokable only for
information-preserving transformations between types in the same
general type category. For example, the cast from <type>int2</type> to
<type>int4</type> can reasonably be implicit, but the cast from
<type>float8</type> to <type>int4</type> should probably be
assignment-only. Cross-type-category casts, such as <type>text</type>
to <type>int4</type>, are best made explicit-only.
</para>
<note>
<para>
Sometimes it is necessary for usability or standards-compliance reasons
to provide multiple implicit casts among a set of types, resulting in
ambiguity that cannot be avoided as above. The parser has a fallback
heuristic based on <firstterm>type categories</firstterm> and <firstterm>preferred
types</firstterm> that can help to provide desired behavior in such cases. See
<xref linkend="sql-createtype"/> for
more information.
</para>