catch the error, for example:

<programlisting>
BEGIN
    SELECT * INTO STRICT myrec FROM emp WHERE empname = myname;
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            RAISE EXCEPTION 'employee % not found', myname;
        WHEN TOO_MANY_ROWS THEN
            RAISE EXCEPTION 'employee % not unique', myname;
END;
</programlisting>
     Successful execution of a command with <literal>STRICT</literal>
     always sets <literal>FOUND</literal> to true.
    </para>

    <para>
     For <command>INSERT</command>/<command>UPDATE</command>/<command>DELETE</command>/<command>MERGE</command> with
     <literal>RETURNING</literal>, <application>PL/pgSQL</application> reports
     an error for more than one returned row, even when
     <literal>STRICT</literal> is not specified.  This is because there
     is no option such as <literal>ORDER BY</literal> with which to determine
     which affected row should be returned.
    </para>

    <para>
     If <literal>print_strict_params</literal> is enabled for the function,
     then when an error is thrown because the requirements
     of <literal>STRICT</literal> are not met, the <literal>DETAIL</literal> part of
     the error message will include information about the parameters
     passed to the command.
     You can change the <literal>print_strict_params</literal>
     setting for all functions by setting
     <varname>plpgsql.print_strict_params</varname>, though only subsequent
     function compilations will be affected.  You can also enable it
     on a per-function basis by using a compiler option, for example:
<programlisting>
CREATE FUNCTION get_userid(username text) RETURNS int
AS $$
#print_strict_params on
DECLARE
userid int;
BEGIN
    SELECT users.userid INTO STRICT userid
        FROM users WHERE users.username = get_userid.username;
    RETURN userid;
END;
$$ LANGUAGE plpgsql;
</programlisting>
     On failure, this function might produce an error message such as
<programlisting>
ERROR:  query returned no rows
DETAIL:  parameters: username = 'nosuchuser'
CONTEXT:  PL/pgSQL function get_userid(text) line 6 at SQL statement
</programlisting>
    </para>

    <note>
     <para>
      The <literal>STRICT</literal> option matches the behavior of
      Oracle PL/SQL's <command>SELECT INTO</command> and related statements.
     </para>
    </note>

   </sect2>

   <sect2 id="plpgsql-statements-executing-dyn">
    <title>Executing Dynamic Commands</title>

    <para>
     Oftentimes you will want to generate dynamic commands inside your
     <application>PL/pgSQL</application> functions, that is, commands
     that will involve different tables or different data types each
     time they are executed.  <application>PL/pgSQL</application>'s
     normal attempts to cache plans for commands (as discussed in
     <xref linkend="plpgsql-plan-caching"/>) will not work in such
     scenarios.  To handle this sort of problem, the
     <command>EXECUTE</command> statement is provided:

<synopsis>
EXECUTE <replaceable class="command">command-string</replaceable> <optional> INTO <optional>STRICT</optional> <replaceable>target</replaceable> </optional> <optional> USING <replaceable>expression</replaceable> <optional>, ... </optional> </optional>;
</synopsis>

     where <replaceable>command-string</replaceable> is an expression
     yielding a string (of type <type>text</type>) containing the
     command to be executed.  The optional <replaceable>target</replaceable>
     is a record variable, a row variable, or a comma-separated list of
     simple variables and record/row fields, into which the results of
     the command will be stored.  The optional <literal>USING</literal> expressions
     supply values to be inserted into the command.
    </para>

    <para>
     No substitution of <application>PL/pgSQL</application> variables is done on the
     computed command string.  Any required variable values must be inserted
     in the command string as it is constructed; or you can use