<application>PL/pgSQL</application> will use <literal>NULL</literal>
        for missing values and extra variables are ignored.  Enabling this
        check will cause <application>PL/pgSQL</application> to throw a
        <literal>WARNING</literal> or <literal>ERROR</literal> whenever the
        number of target variables and the number of source variables are
        different.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="plpgsql-extra-checks-too-many-rows">
      <term><varname>too_many_rows</varname></term>
      <listitem>
       <para>
        Enabling this check will cause <application>PL/pgSQL</application> to
        check if a given query returns more than one row when an
        <literal>INTO</literal> clause is used.  As an <literal>INTO</literal>
        statement will only ever use one row, having a query return multiple
        rows is generally either inefficient and/or nondeterministic and
        therefore is likely an error.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>

    The following example shows the effect of <varname>plpgsql.extra_warnings</varname>
    set to <varname>shadowed_variables</varname>:
<programlisting>
SET plpgsql.extra_warnings TO 'shadowed_variables';

CREATE FUNCTION foo(f1 int) RETURNS int AS $$
DECLARE
f1 int;
BEGIN
RETURN f1;
END;
$$ LANGUAGE plpgsql;
WARNING:  variable "f1" shadows a previously defined variable
LINE 3: f1 int;
        ^
CREATE FUNCTION
</programlisting>
    The below example shows the effects of setting
    <varname>plpgsql.extra_warnings</varname> to
    <varname>strict_multi_assignment</varname>:
<programlisting>
SET plpgsql.extra_warnings TO 'strict_multi_assignment';

CREATE OR REPLACE FUNCTION public.foo()
 RETURNS void
 LANGUAGE plpgsql
AS $$
DECLARE
  x int;
  y int;
BEGIN
  SELECT 1 INTO x, y;
  SELECT 1, 2 INTO x, y;
  SELECT 1, 2, 3 INTO x, y;
END;
$$;

SELECT foo();
WARNING:  number of source and target fields in assignment does not match
DETAIL:  strict_multi_assignment check of extra_warnings is active.
HINT:  Make sure the query returns the exact list of columns.
WARNING:  number of source and target fields in assignment does not match
DETAIL:  strict_multi_assignment check of extra_warnings is active.
HINT:  Make sure the query returns the exact list of columns.

 foo
-----

(1 row)
</programlisting>
   </para>
  </sect2>
 </sect1>

  <!-- **** Porting from Oracle PL/SQL **** -->

 <sect1 id="plpgsql-porting">
  <title>Porting from <productname>Oracle</productname> PL/SQL</title>

  <indexterm zone="plpgsql-porting">
   <primary>Oracle</primary>
   <secondary>porting from PL/SQL to PL/pgSQL</secondary>
  </indexterm>

  <indexterm zone="plpgsql-porting">
   <primary>PL/SQL (Oracle)</primary>
   <secondary>porting to PL/pgSQL</secondary>
  </indexterm>

  <para>
   This section explains differences between
   <productname>PostgreSQL</productname>'s <application>PL/pgSQL</application>
   language and Oracle's <application>PL/SQL</application> language,
   to help developers who port applications from
   <trademark class="registered">Oracle</trademark> to <productname>PostgreSQL</productname>.
  </para>

  <para>
   <application>PL/pgSQL</application> is similar to PL/SQL in many
   aspects. It is a block-structured, imperative language, and all
   variables have to be declared.  Assignments, loops, and conditionals
   are similar.  The main differences you should keep in mind when
   porting from <application>PL/SQL</application> to
   <application>PL/pgSQL</application> are:

    <itemizedlist>
     <listitem>
      <para>
       If a name used in an SQL command could be either a column name of a
       table used in the command or a reference to a variable of the function,
       <application>PL/SQL</application> treats it as a column name.
       By default, <application>PL/pgSQL</application> will throw an error
       complaining that the name is ambiguous.  You can specify
       <literal>plpgsql.variable_conflict</literal>