one or more
    parameters of collatable data types, a collation is identified for each
    function call depending on the collations assigned to the actual
    arguments, as described in <xref linkend="collation"/>.  If a collation is
    successfully identified (i.e., there are no conflicts of implicit
    collations among the arguments) then all the collatable parameters are
    treated as having that collation implicitly.  This will affect the
    behavior of collation-sensitive operations within the function.
    For example, consider

<programlisting>
CREATE FUNCTION less_than(a text, b text) RETURNS boolean AS $$
BEGIN
    RETURN a &lt; b;
END;
$$ LANGUAGE plpgsql;

SELECT less_than(text_field_1, text_field_2) FROM table1;
SELECT less_than(text_field_1, text_field_2 COLLATE "C") FROM table1;
</programlisting>

    The first use of <function>less_than</function> will use the common collation
    of <structfield>text_field_1</structfield> and <structfield>text_field_2</structfield> for
    the comparison, while the second use will use <literal>C</literal> collation.
   </para>

   <para>
    Furthermore, the identified collation is also assumed as the collation of
    any local variables that are of collatable types.  Thus this function
    would not work any differently if it were written as

<programlisting>
CREATE FUNCTION less_than(a text, b text) RETURNS boolean AS $$
DECLARE
    local_a text := a;
    local_b text := b;
BEGIN
    RETURN local_a &lt; local_b;
END;
$$ LANGUAGE plpgsql;
</programlisting>
   </para>

   <para>
    If there are no parameters of collatable data types, or no common
    collation can be identified for them, then parameters and local variables
    use the default collation of their data type (which is usually the
    database's default collation, but could be different for variables of
    domain types).
   </para>

   <para>
    A local variable of a collatable data type can have a different collation
    associated with it by including the <literal>COLLATE</literal> option in its
    declaration, for example

<programlisting>
DECLARE
    local_a text COLLATE "en_US";
</programlisting>

    This option overrides the collation that would otherwise be
    given to the variable according to the rules above.
   </para>

   <para>
    Also, of course explicit <literal>COLLATE</literal> clauses can be written inside
    a function if it is desired to force a particular collation to be used in
    a particular operation.  For example,

<programlisting>
CREATE FUNCTION less_than_c(a text, b text) RETURNS boolean AS $$
BEGIN
    RETURN a &lt; b COLLATE "C";
END;
$$ LANGUAGE plpgsql;
</programlisting>

    This overrides the collations associated with the table columns,
    parameters, or local variables used in the expression, just as would
    happen in a plain SQL command.
   </para>
  </sect2>
  </sect1>

  <sect1 id="plpgsql-expressions">
  <title>Expressions</title>

    <para>
     All expressions used in <application>PL/pgSQL</application>
     statements are processed using the server's main
     <acronym>SQL</acronym> executor.  For example, when you write
     a <application>PL/pgSQL</application> statement like
<synopsis>
IF <replaceable>expression</replaceable> THEN ...
</synopsis>
     <application>PL/pgSQL</application> will evaluate the expression by
     feeding a query like
<synopsis>
SELECT <replaceable>expression</replaceable>
</synopsis>
     to the main SQL engine.  While forming the <command>SELECT</command> command,
     any occurrences of <application>PL/pgSQL</application> variable names
     are replaced by query parameters, as discussed in detail in
     <xref linkend="plpgsql-var-subst"/>.
     This allows the query plan for the <command>SELECT</command> to
     be prepared just once and then reused for subsequent
     evaluations with different values of the variables.  Thus, what
     really happens on first use of an expression is essentially a
     <command>PREPARE</command>