linkend="plpgsql-statements-sql-onerow"/>.
     To process all of the output rows, write the command as the data
     source for a <command>FOR</command> loop, as described in
     <xref linkend="plpgsql-records-iterating"/>.
    </para>

    <para>
     Usually it is not sufficient just to execute statically-defined SQL
     commands.  Typically you'll want a command to use varying data values,
     or even to vary in more fundamental ways such as by using different
     table names at different times.  Again, there are two ways to proceed
     depending on the situation.
    </para>

    <para>
     <application>PL/pgSQL</application> variable values can be
     automatically inserted into optimizable SQL commands, which
     are <command>SELECT</command>, <command>INSERT</command>,
     <command>UPDATE</command>, <command>DELETE</command>,
     <command>MERGE</command>, and certain
     utility commands that incorporate one of these, such
     as <command>EXPLAIN</command> and <command>CREATE TABLE ... AS
     SELECT</command>.  In these commands,
     any <application>PL/pgSQL</application> variable name appearing
     in the command text is replaced by a query parameter, and then the
     current value of the variable is provided as the parameter value
     at run time.  This is exactly like the processing described earlier
     for expressions; for details see <xref linkend="plpgsql-var-subst"/>.
    </para>

    <para>
     When executing an optimizable SQL command in this way,
     <application>PL/pgSQL</application> may cache and re-use the execution
     plan for the command, as discussed in
     <xref linkend="plpgsql-plan-caching"/>.
    </para>

    <para>
     Non-optimizable SQL commands (also called utility commands) are not
     capable of accepting query parameters.  So automatic substitution
     of <application>PL/pgSQL</application> variables does not work in such
     commands.  To include non-constant text in a utility command executed
     from <application>PL/pgSQL</application>, you must build the utility
     command as a string and then <command>EXECUTE</command> it, as
     discussed in <xref linkend="plpgsql-statements-executing-dyn"/>.
    </para>

    <para>
     <command>EXECUTE</command> must also be used if you want to modify
     the command in some other way than supplying a data value, for example
     by changing a table name.
    </para>

    <para>
     Sometimes it is useful to evaluate an expression or <command>SELECT</command>
     query but discard the result, for example when calling a function
     that has side-effects but no useful result value.  To do
     this in <application>PL/pgSQL</application>, use the
     <command>PERFORM</command> statement:

<synopsis>
PERFORM <replaceable>query</replaceable>;
</synopsis>

     This executes <replaceable>query</replaceable> and discards the
     result.  Write the <replaceable>query</replaceable> the same
     way you would write an SQL <command>SELECT</command> command, but replace the
     initial keyword <command>SELECT</command> with <command>PERFORM</command>.
     For <command>WITH</command> queries, use <command>PERFORM</command> and then
     place the query in parentheses.  (In this case, the query can only
     return one row.)
     <application>PL/pgSQL</application> variables will be
     substituted into the query just as described above,
     and the plan is cached in the same way.  Also, the special variable
     <literal>FOUND</literal> is set to true if the query produced at
     least one row, or false if it produced no rows (see
     <xref linkend="plpgsql-statements-diagnostics"/>).
    </para>

    <note>
     <para>
      One might expect that writing <command>SELECT</command> directly
      would accomplish this result, but at
      present the only accepted way to do it is
      <command>PERFORM</command>.  An SQL command that can return rows,
      such as <command>SELECT</command>, will be rejected as an error