merge_db(1, 'dennis');
</programlisting>

     This coding assumes the <literal>unique_violation</literal> error is caused by
     the <command>INSERT</command>, and not by, say, an <command>INSERT</command> in a
     trigger function on the table.  It might also misbehave if there is
     more than one unique index on the table, since it will retry the
     operation regardless of which index caused the error.
     More safety could be had by using the
     features discussed next to check that the trapped error was the one
     expected.
    </para>
    </example>

   <sect3 id="plpgsql-exception-diagnostics">
    <title>Obtaining Information about an Error</title>

    <para>
     Exception handlers frequently need to identify the specific error that
     occurred.  There are two ways to get information about the current
     exception in <application>PL/pgSQL</application>: special variables and the
     <command>GET STACKED DIAGNOSTICS</command> command.
    </para>

    <para>
     Within an exception handler, the special variable
     <varname>SQLSTATE</varname> contains the error code that corresponds to
     the exception that was raised (refer to <xref linkend="errcodes-table"/>
     for a list of possible error codes). The special variable
     <varname>SQLERRM</varname> contains the error message associated with the
     exception. These variables are undefined outside exception handlers.
    </para>

    <para>
     Within an exception handler, one may also retrieve
     information about the current exception by using the
     <command>GET STACKED DIAGNOSTICS</command> command, which has the form:

<synopsis>
GET STACKED DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>item</replaceable> <optional> , ... </optional>;
</synopsis>

     Each <replaceable>item</replaceable> is a key word identifying a status
     value to be assigned to the specified <replaceable>variable</replaceable>
     (which should be of the right data type to receive it).  The currently
     available status items are shown
     in <xref linkend="plpgsql-exception-diagnostics-values"/>.
    </para>

     <table id="plpgsql-exception-diagnostics-values">
      <title>Error Diagnostics Items</title>
      <tgroup cols="3">
       <colspec colname="col1" colwidth="2*"/>
       <colspec colname="col2" colwidth="1*"/>
       <colspec colname="col3" colwidth="2*"/>
       <thead>
        <row>
         <entry>Name</entry>
         <entry>Type</entry>
         <entry>Description</entry>
        </row>
       </thead>
       <tbody>
        <row>
         <entry><literal>RETURNED_SQLSTATE</literal></entry>
         <entry><type>text</type></entry>
         <entry>the SQLSTATE error code of the exception</entry>
        </row>
        <row>
         <entry><literal>COLUMN_NAME</literal></entry>
         <entry><type>text</type></entry>
         <entry>the name of the column related to exception</entry>
        </row>
        <row>
         <entry><literal>CONSTRAINT_NAME</literal></entry>
         <entry><type>text</type></entry>
         <entry>the name of the constraint related to exception</entry>
        </row>
        <row>
         <entry><literal>PG_DATATYPE_NAME</literal></entry>
         <entry><type>text</type></entry>
         <entry>the name of the data type related to exception</entry>
        </row>
        <row>
         <entry><literal>MESSAGE_TEXT</literal></entry>
         <entry><type>text</type></entry>
         <entry>the text of the exception's primary message</entry>
        </row>
        <row>
         <entry><literal>TABLE_NAME</literal></entry>
         <entry><type>text</type></entry>
         <entry>the name of the table related to exception</entry>
        </row>
        <row>
         <entry><literal>SCHEMA_NAME</literal></entry>
         <entry><type>text</type></entry>
         <entry>the name of the schema related to exception</entry>
        </row>
        <row>
         <entry><literal>PG_EXCEPTION_DETAIL</literal></entry>