:= a_output || '' if v_'' ||
    referrer_keys.kind || '' like ''''''''''
    || referrer_keys.key_string || ''''''''''
    then return ''''''  || referrer_keys.referrer_type
    || ''''''; end if;'';
</programlisting>
      The value of <literal>a_output</literal> would then be:
<programlisting>
if v_... like ''...'' then return ''...''; end if;
</programlisting>
     </para>
     <para>
      In the dollar-quoting approach, this becomes:
<programlisting>
a_output := a_output || $$ if v_$$ || referrer_keys.kind || $$ like '$$
    || referrer_keys.key_string || $$'
    then return '$$  || referrer_keys.referrer_type
    || $$'; end if;$$;
</programlisting>
      where we assume we only need to put single quote marks into
      <literal>a_output</literal>, because it will be re-quoted before use.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  </sect2>
  <sect2 id="plpgsql-extra-checks">
   <title>Additional Compile-Time and Run-Time Checks</title>

   <para>
    To aid the user in finding instances of simple but common problems before
    they cause harm, <application>PL/pgSQL</application> provides additional
    <replaceable>checks</replaceable>. When enabled, depending on the configuration, they
    can be used to emit either a <literal>WARNING</literal> or an <literal>ERROR</literal>
    during the compilation of a function. A function which has received
    a <literal>WARNING</literal> can be executed without producing further messages,
    so you are advised to test in a separate development environment.
   </para>

   <para>
    Setting <varname>plpgsql.extra_warnings</varname>, or
    <varname>plpgsql.extra_errors</varname>, as appropriate, to <literal>"all"</literal>
    is encouraged in development and/or testing environments.
   </para>

   <para>
    These additional checks are enabled through the configuration variables
    <varname>plpgsql.extra_warnings</varname> for warnings and
    <varname>plpgsql.extra_errors</varname> for errors. Both can be set either to
    a comma-separated list of checks, <literal>"none"</literal> or
    <literal>"all"</literal>. The default is <literal>"none"</literal>. Currently
    the list of available checks includes:
    <variablelist>
     <varlistentry id="plpgsql-extra-checks-shadowed-variables">
      <term><varname>shadowed_variables</varname></term>
      <listitem>
       <para>
        Checks if a declaration shadows a previously defined variable.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="plpgsql-extra-checks-strict-multi-assignment">
      <term><varname>strict_multi_assignment</varname></term>
      <listitem>
       <para>
        Some <application>PL/pgSQL</application> commands allow assigning
        values to more than one variable at a time, such as
        <command>SELECT INTO</command>.  Typically, the number of target
        variables and the number of source variables should match, though
        <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>