<function>quote_literal</function> except that
     when called with a null argument it returns the string <literal>NULL</literal>.
     For example,
<programlisting>
EXECUTE 'UPDATE tbl SET '
        || quote_ident(colname)
        || ' = '
        || quote_nullable(newvalue)
        || ' WHERE key = '
        || quote_nullable(keyvalue);
</programlisting>
     If you are dealing with values that might be null, you should usually
     use <function>quote_nullable</function> in place of <function>quote_literal</function>.
    </para>

    <para>
     As always, care must be taken to ensure that null values in a query do
     not deliver unintended results.  For example the <literal>WHERE</literal> clause
<programlisting>
'WHERE key = ' || quote_nullable(keyvalue)
</programlisting>
     will never succeed if <literal>keyvalue</literal> is null, because the
     result of using the equality operator <literal>=</literal> with a null operand
     is always null.  If you wish null to work like an ordinary key value,
     you would need to rewrite the above as
<programlisting>
'WHERE key IS NOT DISTINCT FROM ' || quote_nullable(keyvalue)
</programlisting>
     (At present, <literal>IS NOT DISTINCT FROM</literal> is handled much less
     efficiently than <literal>=</literal>, so don't do this unless you must.
     See <xref linkend="functions-comparison"/> for
     more information on nulls and <literal>IS DISTINCT</literal>.)
    </para>

    <para>
     Note that dollar quoting is only useful for quoting fixed text.
     It would be a very bad idea to try to write this example as:
<programlisting>
EXECUTE 'UPDATE tbl SET '
        || quote_ident(colname)
        || ' = $$'
        || newvalue
        || '$$ WHERE key = '
        || quote_literal(keyvalue);
</programlisting>
     because it would break if the contents of <literal>newvalue</literal>
     happened to contain <literal>$$</literal>.  The same objection would
     apply to any other dollar-quoting delimiter you might pick.
     So, to safely quote text that is not known in advance, you
     <emphasis>must</emphasis> use <function>quote_literal</function>,
     <function>quote_nullable</function>, or <function>quote_ident</function>, as appropriate.
    </para>

    <para>
     Dynamic SQL statements can also be safely constructed using the
     <function>format</function> function (see <xref
     linkend="functions-string-format"/>). For example:
<programlisting>
EXECUTE format('UPDATE tbl SET %I = %L '
   'WHERE key = %L', colname, newvalue, keyvalue);
</programlisting>
     <literal>%I</literal> is equivalent to <function>quote_ident</function>, and
     <literal>%L</literal> is equivalent to <function>quote_nullable</function>.
     The <function>format</function> function can be used in conjunction with
     the <literal>USING</literal> clause:
<programlisting>
EXECUTE format('UPDATE tbl SET %I = $1 WHERE key = $2', colname)
   USING newvalue, keyvalue;
</programlisting>
     This form is 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