<productname>PostgreSQL</productname> 9.1, <command>RAISE</command> without
     parameters was interpreted as re-throwing the error from the block
     containing the active exception handler.  Thus an <literal>EXCEPTION</literal>
     clause nested within that handler could not catch it, even if the
     <command>RAISE</command> was within the nested <literal>EXCEPTION</literal> clause's
     block. This was deemed surprising as well as being incompatible with
     Oracle's PL/SQL.
    </para>
   </note>

   <para>
    If no condition name nor SQLSTATE is specified in a
    <command>RAISE EXCEPTION</command> command, the default is to use
    <literal>raise_exception</literal> (<literal>P0001</literal>).
    If no message text is specified, the default is to use the condition
    name or SQLSTATE as message text.
   </para>

   <note>
    <para>
     When specifying an error code by SQLSTATE code, you are not
     limited to the predefined error codes, but can select any
     error code consisting of five digits and/or upper-case ASCII
     letters, other than <literal>00000</literal>.  It is recommended that
     you avoid throwing error codes that end in three zeroes, because
     these are category codes and can only be trapped by trapping
     the whole category.
    </para>
   </note>

  </sect2>

  <sect2 id="plpgsql-statements-assert">
   <title>Checking Assertions</title>

   <indexterm>
    <primary>ASSERT</primary>
    <secondary>in PL/pgSQL</secondary>
   </indexterm>

   <indexterm>
    <primary>assertions</primary>
    <secondary>in PL/pgSQL</secondary>
   </indexterm>

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

   <para>
    The <command>ASSERT</command> statement is a convenient shorthand for
    inserting debugging checks into <application>PL/pgSQL</application>
    functions.

<synopsis>
ASSERT <replaceable class="parameter">condition</replaceable> <optional> , <replaceable class="parameter">message</replaceable> </optional>;
</synopsis>

    The <replaceable class="parameter">condition</replaceable> is a Boolean
    expression that is expected to always evaluate to true; if it does,
    the <command>ASSERT</command> statement does nothing further.  If the
    result is false or null, then an <literal>ASSERT_FAILURE</literal> exception
    is raised.  (If an error occurs while evaluating
    the <replaceable class="parameter">condition</replaceable>, it is
    reported as a normal error.)
   </para>

   <para>
    If the optional <replaceable class="parameter">message</replaceable> is
    provided, it is an expression whose result (if not null) replaces the
    default error message text <quote>assertion failed</quote>, should
    the <replaceable class="parameter">condition</replaceable> fail.
    The <replaceable class="parameter">message</replaceable> expression is
    not evaluated in the normal case where the assertion succeeds.
   </para>

   <para>
    Testing of assertions can be enabled or disabled via the configuration
    parameter <literal>plpgsql.check_asserts</literal>, which takes a Boolean
    value; the default is <literal>on</literal>.  If this parameter
    is <literal>off</literal> then <command>ASSERT</command> statements do nothing.
   </para>

   <para>
    Note that <command>ASSERT</command> is meant for detecting program
    bugs, not for reporting ordinary error conditions.  Use
    the <command>RAISE</command> statement, described above, for that.
   </para>

  </sect2>

 </sect1>

 <sect1 id="plpgsql-trigger">
  <title>Trigger Functions</title>

  <indexterm zone="plpgsql-trigger">
   <primary>trigger</primary>
   <secondary>in PL/pgSQL</secondary>
  </indexterm>

  <para>
   <application>PL/pgSQL</application> can be used to define trigger
   functions on data changes or database events.
   A trigger function is created with the <command>CREATE FUNCTION</command>
   command, declaring it as a function with