example,
<programlisting>
&lt;&lt;block&gt;&gt;
DECLARE
    foo int;
BEGIN
    foo := ...;
    INSERT INTO dest (col) SELECT block.foo + bar FROM src;
</programlisting>
    Here <literal>block.foo</literal> means the variable even if there is a column
    <literal>foo</literal> in <literal>src</literal>.  Function parameters, as well as
    special variables such as <literal>FOUND</literal>, can be qualified by the
    function's name, because they are implicitly declared in an outer block
    labeled with the function's name.
   </para>

   <para>
    Sometimes it is impractical to fix all the ambiguous references in a
    large body of <application>PL/pgSQL</application> code.  In such cases you can
    specify that <application>PL/pgSQL</application> should resolve ambiguous references
    as the variable (which is compatible with <application>PL/pgSQL</application>'s
    behavior before <productname>PostgreSQL</productname> 9.0), or as the
    table column (which is compatible with some other systems such as
    <productname>Oracle</productname>).
   </para>

   <indexterm>
     <primary><varname>plpgsql.variable_conflict</varname> configuration parameter</primary>
   </indexterm>

   <para>
    To change this behavior on a system-wide basis, set the configuration
    parameter <literal>plpgsql.variable_conflict</literal> to one of
    <literal>error</literal>, <literal>use_variable</literal>, or
    <literal>use_column</literal> (where <literal>error</literal> is the factory default).
    This parameter affects subsequent compilations
    of statements in <application>PL/pgSQL</application> functions, but not statements
    already compiled in the current session.
    Because changing this setting
    can cause unexpected changes in the behavior of <application>PL/pgSQL</application>
    functions, it can only be changed by a superuser.
   </para>

   <para>
    You can also set the behavior on a function-by-function basis, by
    inserting one of these special commands at the start of the function
    text:
<programlisting>
#variable_conflict error
#variable_conflict use_variable
#variable_conflict use_column
</programlisting>
    These commands affect only the function they are written in, and override
    the setting of <literal>plpgsql.variable_conflict</literal>.  An example is
<programlisting>
CREATE FUNCTION stamp_user(id int, comment text) RETURNS void AS $$
    #variable_conflict use_variable
    DECLARE
        curtime timestamp := now();
    BEGIN
        UPDATE users SET last_modified = curtime, comment = comment
          WHERE users.id = id;
    END;
$$ LANGUAGE plpgsql;
</programlisting>
    In the <literal>UPDATE</literal> command, <literal>curtime</literal>, <literal>comment</literal>,
    and <literal>id</literal> will refer to the function's variable and parameters
    whether or not <literal>users</literal> has columns of those names.  Notice
    that we had to qualify the reference to <literal>users.id</literal> in the
    <literal>WHERE</literal> clause to make it refer to the table column.
    But we did not have to qualify the reference to <literal>comment</literal>
    as a target in the <literal>UPDATE</literal> list, because syntactically
    that must be a column of <literal>users</literal>.  We could write the same
    function without depending on the <literal>variable_conflict</literal> setting
    in this way:
<programlisting>
CREATE FUNCTION stamp_user(id int, comment text) RETURNS void AS $$
    &lt;&lt;fn&gt;&gt;
    DECLARE
        curtime timestamp := now();
    BEGIN
        UPDATE users SET last_modified = fn.curtime, comment = stamp_user.comment
          WHERE users.id = stamp_user.id;
    END;
$$ LANGUAGE plpgsql;
</programlisting>
   </para>

   <para>
    Variable substitution does not happen in a command string given
    to <command>EXECUTE</command> or one of its variants.  If you need to
    insert a varying value into such a command, do so as part of
    constructing the string