However, automatic casting is only done for
    casts that are marked <quote>OK to apply implicitly</quote>
    in the system catalogs.  Other casts must be invoked with
    explicit casting syntax.  This restriction is intended to prevent
    surprising conversions from being applied silently.
   </para>

   <para>
    It is also possible to specify a type cast using a function-like
    syntax:
<synopsis>
<replaceable>typename</replaceable> ( <replaceable>expression</replaceable> )
</synopsis>
    However, this only works for types whose names are also valid as
    function names.  For example, <literal>double precision</literal>
    cannot be used this way, but the equivalent <literal>float8</literal>
    can.  Also, the names <literal>interval</literal>, <literal>time</literal>, and
    <literal>timestamp</literal> can only be used in this fashion if they are
    double-quoted, because of syntactic conflicts.  Therefore, the use of
    the function-like cast syntax leads to inconsistencies and should
    probably be avoided.
   </para>

   <note>
    <para>
     The function-like syntax is in fact just a function call.  When
     one of the two standard cast syntaxes is used to do a run-time
     conversion, it will internally invoke a registered function to
     perform the conversion.  By convention, these conversion functions
     have the same name as their output type, and thus the <quote>function-like
     syntax</quote> is nothing more than a direct invocation of the underlying
     conversion function.  Obviously, this is not something that a portable
     application should rely on.  For further details see
     <xref linkend="sql-createcast"/>.
    </para>
   </note>
  </sect2>

  <sect2 id="sql-syntax-collate-exprs">
   <title>Collation Expressions</title>

   <indexterm>
    <primary>COLLATE</primary>
   </indexterm>

   <para>
    The <literal>COLLATE</literal> clause overrides the collation of
    an expression.  It is appended to the expression it applies to:
<synopsis>
<replaceable>expr</replaceable> COLLATE <replaceable>collation</replaceable>
</synopsis>
    where <replaceable>collation</replaceable> is a possibly
    schema-qualified identifier.  The <literal>COLLATE</literal>
    clause binds tighter than operators; parentheses can be used when
    necessary.
   </para>

   <para>
    If no collation is explicitly specified, the database system
    either derives a collation from the columns involved in the
    expression, or it defaults to the default collation of the
    database if no column is involved in the expression.
   </para>

   <para>
    The two common uses of the <literal>COLLATE</literal> clause are
    overriding the sort order in an <literal>ORDER BY</literal> clause, for
    example:
<programlisting>
SELECT a, b, c FROM tbl WHERE ... ORDER BY a COLLATE "C";
</programlisting>
    and overriding the collation of a function or operator call that
    has locale-sensitive results, for example:
<programlisting>
SELECT * FROM tbl WHERE a &gt; 'foo' COLLATE "C";
</programlisting>
    Note that in the latter case the <literal>COLLATE</literal> clause is
    attached to an input argument of the operator we wish to affect.
    It doesn't matter which argument of the operator or function call the
    <literal>COLLATE</literal> clause is attached to, because the collation that is
    applied by the operator or function is derived by considering all
    arguments, and an explicit <literal>COLLATE</literal> clause will override the
    collations of all other arguments.  (Attaching non-matching
    <literal>COLLATE</literal> clauses to more than one argument, however, is an
    error.  For more details see <xref linkend="collation"/>.)
    Thus, this gives the same result as the previous example:
<programlisting>
SELECT * FROM tbl WHERE a COLLATE "C" &gt; 'foo';
</programlisting>
    But this is an error:
<programlisting>
SELECT * FROM tbl WHERE (a &gt; 'foo') COLLATE "C";
</programlisting>
    because