better because the variables are handled in their native
     data type format, rather than unconditionally converting them to
     text and quoting them via <literal>%L</literal>.  It is also more efficient.
    </para>
   </example>

    <para>
     A much larger example of a dynamic command and
     <command>EXECUTE</command> can be seen in <xref
     linkend="plpgsql-porting-ex2"/>, which builds and executes a
     <command>CREATE FUNCTION</command> command to define a new function.
    </para>
   </sect2>

   <sect2 id="plpgsql-statements-diagnostics">
    <title>Obtaining the Result Status</title>

    <para>
     There are several ways to determine the effect of a command. The
     first method is to use the <command>GET DIAGNOSTICS</command>
     command, which has the form:

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

     This command allows retrieval of system status indicators.
     <literal>CURRENT</literal> is a noise word (but see also <command>GET STACKED
     DIAGNOSTICS</command> in <xref linkend="plpgsql-exception-diagnostics"/>).
     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-current-diagnostics-values"/>.  Colon-equal
     (<literal>:=</literal>) can be used instead of the SQL-standard <literal>=</literal>
     token.  An example:
<programlisting>
GET DIAGNOSTICS integer_var = ROW_COUNT;
</programlisting>
    </para>

     <table id="plpgsql-current-diagnostics-values">
      <title>Available Diagnostics Items</title>
      <tgroup cols="3">
       <colspec colname="col1" colwidth="1*"/>
       <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><varname>ROW_COUNT</varname></entry>
         <entry><type>bigint</type></entry>
         <entry>the number of rows processed by the most
          recent <acronym>SQL</acronym> command</entry>
        </row>
        <row>
         <entry><literal>PG_CONTEXT</literal></entry>
         <entry><type>text</type></entry>
         <entry>line(s) of text describing the current call stack
          (see <xref linkend="plpgsql-call-stack"/>)</entry>
        </row>
        <row>
         <entry><literal>PG_ROUTINE_OID</literal></entry>
         <entry><type>oid</type></entry>
         <entry>OID of the current function</entry>
        </row>
       </tbody>
      </tgroup>
     </table>

    <para>
     The second method to determine the effects of a command is to check the
     special variable named <literal>FOUND</literal>, which is of
     type <type>boolean</type>.  <literal>FOUND</literal> starts out
     false within each <application>PL/pgSQL</application> function call.
     It is set by each of the following types of statements:

         <itemizedlist>
          <listitem>
           <para>
            A <command>SELECT INTO</command> statement sets
            <literal>FOUND</literal> true if a row is assigned, false if no
            row is returned.
           </para>
          </listitem>
          <listitem>
           <para>
            A <command>PERFORM</command> statement sets <literal>FOUND</literal>
            true if it produces (and discards) one or more rows, false if
            no row is produced.
           </para>
          </listitem>
          <listitem>
           <para>
            <command>UPDATE</command>, <command>INSERT</command>, <command>DELETE</command>,
            and <command>MERGE</command>
            statements set