Sophie

Sophie

distrib > Mageia > 7 > armv7hl > media > core-updates > by-pkgid > 8898dd367b2cdca21ea56f51161fb737 > files > 554

postgresql9.6-docs-9.6.17-2.mga7.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Basic Statements</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.6.17 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PL/pgSQL - SQL Procedural Language"
HREF="plpgsql.html"><LINK
REL="PREVIOUS"
TITLE="Expressions"
HREF="plpgsql-expressions.html"><LINK
REL="NEXT"
TITLE="Control Structures"
HREF="plpgsql-control-structures.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2020-02-24T19:56:52"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="4"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.6.17 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="Expressions"
HREF="plpgsql-expressions.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpgsql.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 41. <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> - <ACRONYM
CLASS="ACRONYM"
>SQL</ACRONYM
> Procedural Language</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="Control Structures"
HREF="plpgsql-control-structures.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PLPGSQL-STATEMENTS"
>41.5. Basic Statements</A
></H1
><P
>    In this section and the following ones, we describe all the statement
    types that are explicitly understood by
    <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>.
    Anything not recognized as one of these statement types is presumed
    to be an SQL command and is sent to the main database engine to execute,
    as described in <A
HREF="plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-NORESULT"
>Section 41.5.2</A
>
    and <A
HREF="plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW"
>Section 41.5.3</A
>.
   </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-ASSIGNMENT"
>41.5.1. Assignment</A
></H2
><P
>     An assignment of a value to a <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>
     variable is written as:
</P><PRE
CLASS="SYNOPSIS"
><TT
CLASS="REPLACEABLE"
><I
>variable</I
></TT
> { := | = } <TT
CLASS="REPLACEABLE"
><I
>expression</I
></TT
>;</PRE
><P>
     As explained previously, the expression in such a statement is evaluated
     by means of an SQL <TT
CLASS="COMMAND"
>SELECT</TT
> command sent to the main
     database engine.  The expression must yield a single value (possibly
     a row value, if the variable is a row or record variable).  The target
     variable can be a simple variable (optionally qualified with a block
     name), a field of a row or record variable, or an element of an array
     that is a simple variable or field.  Equal (<TT
CLASS="LITERAL"
>=</TT
>) can be
     used instead of PL/SQL-compliant <TT
CLASS="LITERAL"
>:=</TT
>.
    </P
><P
>     If the expression's result data type doesn't match the variable's
     data type, the value will be coerced as though by an assignment cast
     (see <A
HREF="typeconv-query.html"
>Section 10.4</A
>).  If no assignment cast is known
     for the pair of data types involved, the <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>
     interpreter will attempt to convert the result value textually, that is
     by applying the result type's output function followed by the variable
     type's input function.  Note that this could result in run-time errors
     generated by the input function, if the string form of the result value
     is not acceptable to the input function.
    </P
><P
>     Examples:
</P><PRE
CLASS="PROGRAMLISTING"
>tax := subtotal * 0.06;
my_record.user_id := 20;</PRE
><P>
    </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-SQL-NORESULT"
>41.5.2. Executing a Command With No Result</A
></H2
><P
>     For any SQL command that does not return rows, for example
     <TT
CLASS="COMMAND"
>INSERT</TT
> without a <TT
CLASS="LITERAL"
>RETURNING</TT
> clause, you can
     execute the command within a <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> function
     just by writing the command.
    </P
><P
>     Any <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> variable name appearing
     in the command text is treated as a 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 <A
HREF="plpgsql-implementation.html#PLPGSQL-VAR-SUBST"
>Section 41.10.1</A
>.
    </P
><P
>     When executing a SQL command in this way,
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> may cache and re-use the execution
     plan for the command, as discussed in
     <A
HREF="plpgsql-implementation.html#PLPGSQL-PLAN-CACHING"
>Section 41.10.2</A
>.
    </P
><P
>     Sometimes it is useful to evaluate an expression or <TT
CLASS="COMMAND"
>SELECT</TT
>
     query but discard the result, for example when calling a function
     that has side-effects but no useful result value.  To do
     this in <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>, use the
     <TT
CLASS="COMMAND"
>PERFORM</TT
> statement:

</P><PRE
CLASS="SYNOPSIS"
>PERFORM <TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
>;</PRE
><P>

     This executes <TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
> and discards the
     result.  Write the <TT
CLASS="REPLACEABLE"
><I
>query</I
></TT
> the same
     way you would write an SQL <TT
CLASS="COMMAND"
>SELECT</TT
> command, but replace the
     initial keyword <TT
CLASS="COMMAND"
>SELECT</TT
> with <TT
CLASS="COMMAND"
>PERFORM</TT
>.
     For <TT
CLASS="COMMAND"
>WITH</TT
> queries, use <TT
CLASS="COMMAND"
>PERFORM</TT
> and then
     place the query in parentheses.  (In this case, the query can only
     return one row.)
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> variables will be
     substituted into the query just as for commands that return no result,
     and the plan is cached in the same way.  Also, the special variable
     <TT
CLASS="LITERAL"
>FOUND</TT
> is set to true if the query produced at
     least one row, or false if it produced no rows (see
     <A
HREF="plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS"
>Section 41.5.5</A
>).
    </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>      One might expect that writing <TT
CLASS="COMMAND"
>SELECT</TT
> directly
      would accomplish this result, but at
      present the only accepted way to do it is
      <TT
CLASS="COMMAND"
>PERFORM</TT
>.  A SQL command that can return rows,
      such as <TT
CLASS="COMMAND"
>SELECT</TT
>, will be rejected as an error
      unless it has an <TT
CLASS="LITERAL"
>INTO</TT
> clause as discussed in the
      next section.
     </P
></BLOCKQUOTE
></DIV
><P
>     An example:
</P><PRE
CLASS="PROGRAMLISTING"
>PERFORM create_mv('cs_session_page_requests_mv', my_query);</PRE
><P>
    </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-SQL-ONEROW"
>41.5.3. Executing a Query with a Single-row Result</A
></H2
><P
>     The result of a SQL command yielding a single row (possibly of multiple
     columns) can be assigned to a record variable, row-type variable, or list
     of scalar variables.  This is done by writing the base SQL command and
     adding an <TT
CLASS="LITERAL"
>INTO</TT
> clause.  For example,

</P><PRE
CLASS="SYNOPSIS"
>SELECT <TT
CLASS="REPLACEABLE"
><I
>select_expressions</I
></TT
> INTO [<SPAN
CLASS="OPTIONAL"
>STRICT</SPAN
>] <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
> FROM ...;
INSERT ... RETURNING <TT
CLASS="REPLACEABLE"
><I
>expressions</I
></TT
> INTO [<SPAN
CLASS="OPTIONAL"
>STRICT</SPAN
>] <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
>;
UPDATE ... RETURNING <TT
CLASS="REPLACEABLE"
><I
>expressions</I
></TT
> INTO [<SPAN
CLASS="OPTIONAL"
>STRICT</SPAN
>] <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
>;
DELETE ... RETURNING <TT
CLASS="REPLACEABLE"
><I
>expressions</I
></TT
> INTO [<SPAN
CLASS="OPTIONAL"
>STRICT</SPAN
>] <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
>;</PRE
><P>

     where <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
> can be a record variable, a row
     variable, or a comma-separated list of simple variables and
     record/row fields.
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> variables will be
     substituted into the rest of the query, and the plan is cached,
     just as described above for commands that do not return rows.
     This works for <TT
CLASS="COMMAND"
>SELECT</TT
>,
     <TT
CLASS="COMMAND"
>INSERT</TT
>/<TT
CLASS="COMMAND"
>UPDATE</TT
>/<TT
CLASS="COMMAND"
>DELETE</TT
> with
     <TT
CLASS="LITERAL"
>RETURNING</TT
>, and utility commands that return row-set
     results (such as <TT
CLASS="COMMAND"
>EXPLAIN</TT
>).
     Except for the <TT
CLASS="LITERAL"
>INTO</TT
> clause, the SQL command is the same
     as it would be written outside <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>.
    </P
><DIV
CLASS="TIP"
><BLOCKQUOTE
CLASS="TIP"
><P
><B
>Tip: </B
>     Note that this interpretation of <TT
CLASS="COMMAND"
>SELECT</TT
> with <TT
CLASS="LITERAL"
>INTO</TT
>
     is quite different from <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
>'s regular
     <TT
CLASS="COMMAND"
>SELECT INTO</TT
> command, wherein the <TT
CLASS="LITERAL"
>INTO</TT
>
     target is a newly created table.  If you want to create a table from a
     <TT
CLASS="COMMAND"
>SELECT</TT
> result inside a
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> function, use the syntax
     <TT
CLASS="COMMAND"
>CREATE TABLE ... AS SELECT</TT
>.
    </P
></BLOCKQUOTE
></DIV
><P
>     If a row or a variable list is used as target, the query's result columns
     must exactly match the structure of the target as to number and data
     types, or else a run-time error
     occurs.  When a record variable is the target, it automatically
     configures itself to the row type of the query result columns.
    </P
><P
>     The <TT
CLASS="LITERAL"
>INTO</TT
> clause can appear almost anywhere in the SQL
     command.  Customarily it is written either just before or just after
     the list of <TT
CLASS="REPLACEABLE"
><I
>select_expressions</I
></TT
> in a
     <TT
CLASS="COMMAND"
>SELECT</TT
> command, or at the end of the command for other
     command types.  It is recommended that you follow this convention
     in case the <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> parser becomes
     stricter in future versions.
    </P
><P
>     If <TT
CLASS="LITERAL"
>STRICT</TT
> is not specified in the <TT
CLASS="LITERAL"
>INTO</TT
>
     clause, then <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
> will be set to the first
     row returned by the query, or to nulls if the query returned no rows.
     (Note that <SPAN
CLASS="QUOTE"
>"the first row"</SPAN
> is not
     well-defined unless you've used <TT
CLASS="LITERAL"
>ORDER BY</TT
>.)  Any result rows
     after the first row are discarded.
     You can check the special <TT
CLASS="LITERAL"
>FOUND</TT
> variable (see
     <A
HREF="plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS"
>Section 41.5.5</A
>) to
     determine whether a row was returned:

</P><PRE
CLASS="PROGRAMLISTING"
>SELECT * INTO myrec FROM emp WHERE empname = myname;
IF NOT FOUND THEN
    RAISE EXCEPTION 'employee % not found', myname;
END IF;</PRE
><P>

     If the <TT
CLASS="LITERAL"
>STRICT</TT
> option is specified, the query must
     return exactly one row or a run-time error will be reported, either
     <TT
CLASS="LITERAL"
>NO_DATA_FOUND</TT
> (no rows) or <TT
CLASS="LITERAL"
>TOO_MANY_ROWS</TT
>
     (more than one row). You can use an exception block if you wish
     to catch the error, for example:

</P><PRE
CLASS="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;</PRE
><P>
     Successful execution of a command with <TT
CLASS="LITERAL"
>STRICT</TT
>
     always sets <TT
CLASS="LITERAL"
>FOUND</TT
> to true.
    </P
><P
>     For <TT
CLASS="COMMAND"
>INSERT</TT
>/<TT
CLASS="COMMAND"
>UPDATE</TT
>/<TT
CLASS="COMMAND"
>DELETE</TT
> with
     <TT
CLASS="LITERAL"
>RETURNING</TT
>, <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> reports
     an error for more than one returned row, even when
     <TT
CLASS="LITERAL"
>STRICT</TT
> is not specified.  This is because there
     is no option such as <TT
CLASS="LITERAL"
>ORDER BY</TT
> with which to determine
     which affected row should be returned.
    </P
><P
>     If <TT
CLASS="LITERAL"
>print_strict_params</TT
> is enabled for the function,
     then when an error is thrown because the requirements
     of <TT
CLASS="LITERAL"
>STRICT</TT
> are not met, the <TT
CLASS="LITERAL"
>DETAIL</TT
> part of
     the error message will include information about the parameters
     passed to the query.
     You can change the <TT
CLASS="LITERAL"
>print_strict_params</TT
>
     setting for all functions by setting
     <TT
CLASS="VARNAME"
>plpgsql.print_strict_params</TT
>, 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:
</P><PRE
CLASS="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;</PRE
><P>
     On failure, this function might produce an error message such as
</P><PRE
CLASS="PROGRAMLISTING"
>ERROR:  query returned no rows
DETAIL:  parameters: $1 = 'nosuchuser'
CONTEXT:  PL/pgSQL function get_userid(text) line 6 at SQL statement</PRE
><P>
    </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>      The <TT
CLASS="LITERAL"
>STRICT</TT
> option matches the behavior of
      Oracle PL/SQL's <TT
CLASS="COMMAND"
>SELECT INTO</TT
> and related statements.
     </P
></BLOCKQUOTE
></DIV
><P
>     To handle cases where you need to process multiple result rows
     from a SQL query, see <A
HREF="plpgsql-control-structures.html#PLPGSQL-RECORDS-ITERATING"
>Section 41.6.4</A
>.
    </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-EXECUTING-DYN"
>41.5.4. Executing Dynamic Commands</A
></H2
><P
>     Oftentimes you will want to generate dynamic commands inside your
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> functions, that is, commands
     that will involve different tables or different data types each
     time they are executed.  <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>'s
     normal attempts to cache plans for commands (as discussed in
     <A
HREF="plpgsql-implementation.html#PLPGSQL-PLAN-CACHING"
>Section 41.10.2</A
>) will not work in such
     scenarios.  To handle this sort of problem, the
     <TT
CLASS="COMMAND"
>EXECUTE</TT
> statement is provided:

</P><PRE
CLASS="SYNOPSIS"
>EXECUTE <TT
CLASS="REPLACEABLE"
><I
>command-string</I
></TT
> [<SPAN
CLASS="OPTIONAL"
> INTO [<SPAN
CLASS="OPTIONAL"
>STRICT</SPAN
>] <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
> </SPAN
>] [<SPAN
CLASS="OPTIONAL"
> USING <TT
CLASS="REPLACEABLE"
><I
>expression</I
></TT
> [<SPAN
CLASS="OPTIONAL"
>, ... </SPAN
>] </SPAN
>];</PRE
><P>

     where <TT
CLASS="REPLACEABLE"
><I
>command-string</I
></TT
> is an expression
     yielding a string (of type <TT
CLASS="TYPE"
>text</TT
>) containing the
     command to be executed.  The optional <TT
CLASS="REPLACEABLE"
><I
>target</I
></TT
>
     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 <TT
CLASS="LITERAL"
>USING</TT
> expressions
     supply values to be inserted into the command.
    </P
><P
>     No substitution of <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> 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 parameters
     as described below.
    </P
><P
>     Also, there is no plan caching for commands executed via
     <TT
CLASS="COMMAND"
>EXECUTE</TT
>.  Instead, the command is always planned
     each time the statement is run. Thus the command
     string can be dynamically created within the function to perform
     actions on different tables and columns.
    </P
><P
>     The <TT
CLASS="LITERAL"
>INTO</TT
> clause specifies where the results of
     a SQL command returning rows should be assigned. If a row
     or variable list is provided, it must exactly match the structure
     of the query's results (when a
     record variable is used, it will configure itself to match the
     result structure automatically). If multiple rows are returned,
     only the first will be assigned to the <TT
CLASS="LITERAL"
>INTO</TT
>
     variable. If no rows are returned, NULL is assigned to the
     <TT
CLASS="LITERAL"
>INTO</TT
> variable(s). If no <TT
CLASS="LITERAL"
>INTO</TT
>
     clause is specified, the query results are discarded.
    </P
><P
>     If the <TT
CLASS="LITERAL"
>STRICT</TT
> option is given, an error is reported
     unless the query produces exactly one row.
    </P
><P
>     The command string can use parameter values, which are referenced
     in the command as <TT
CLASS="LITERAL"
>$1</TT
>, <TT
CLASS="LITERAL"
>$2</TT
>, etc.
     These symbols refer to values supplied in the <TT
CLASS="LITERAL"
>USING</TT
>
     clause.  This method is often preferable to inserting data values
     into the command string as text: it avoids run-time overhead of
     converting the values to text and back, and it is much less prone
     to SQL-injection attacks since there is no need for quoting or escaping.
     An example is:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE 'SELECT count(*) FROM mytable WHERE inserted_by = $1 AND inserted &lt;= $2'
   INTO c
   USING checked_user, checked_date;</PRE
><P>
    </P
><P
>     Note that parameter symbols can only be used for data values
     &mdash; if you want to use dynamically determined table or column
     names, you must insert them into the command string textually.
     For example, if the preceding query needed to be done against a
     dynamically selected table, you could do this:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE 'SELECT count(*) FROM '
    || quote_ident(tabname)
    || ' WHERE inserted_by = $1 AND inserted &lt;= $2'
   INTO c
   USING checked_user, checked_date;</PRE
><P>
     A cleaner approach is to use <CODE
CLASS="FUNCTION"
>format()</CODE
>'s <TT
CLASS="LITERAL"
>%I</TT
>
     specification for table or column names (strings separated by a
     newline are concatenated):
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE format('SELECT count(*) FROM %I '
   'WHERE inserted_by = $1 AND inserted &lt;= $2', tabname)
   INTO c
   USING checked_user, checked_date;</PRE
><P>
     Another restriction on parameter symbols is that they only work in
     <TT
CLASS="COMMAND"
>SELECT</TT
>, <TT
CLASS="COMMAND"
>INSERT</TT
>, <TT
CLASS="COMMAND"
>UPDATE</TT
>, and
     <TT
CLASS="COMMAND"
>DELETE</TT
> commands.  In other statement
     types (generically called utility statements), you must insert
     values textually even if they are just data values.
    </P
><P
>     An <TT
CLASS="COMMAND"
>EXECUTE</TT
> with a simple constant command string and some
     <TT
CLASS="LITERAL"
>USING</TT
> parameters, as in the first example above, is
     functionally equivalent to just writing the command directly in
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> and allowing replacement of
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> variables to happen automatically.
     The important difference is that <TT
CLASS="COMMAND"
>EXECUTE</TT
> will re-plan
     the command on each execution, generating a plan that is specific
     to the current parameter values; whereas
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> may otherwise create a generic plan
     and cache it for re-use.  In situations where the best plan depends
     strongly on the parameter values, it can be helpful to use
     <TT
CLASS="COMMAND"
>EXECUTE</TT
> to positively ensure that a generic plan is not
     selected.
    </P
><P
>     <TT
CLASS="COMMAND"
>SELECT INTO</TT
> is not currently supported within
     <TT
CLASS="COMMAND"
>EXECUTE</TT
>; instead, execute a plain <TT
CLASS="COMMAND"
>SELECT</TT
>
     command and specify <TT
CLASS="LITERAL"
>INTO</TT
> as part of the <TT
CLASS="COMMAND"
>EXECUTE</TT
>
     itself.
    </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>     The <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
>
     <TT
CLASS="COMMAND"
>EXECUTE</TT
> statement is not related to the
     <A
HREF="sql-execute.html"
>EXECUTE</A
> SQL
     statement supported by the
     <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> server. The server's
     <TT
CLASS="COMMAND"
>EXECUTE</TT
> statement cannot be used directly within
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> functions (and is not needed).
    </P
></BLOCKQUOTE
></DIV
><DIV
CLASS="EXAMPLE"
><A
NAME="PLPGSQL-QUOTE-LITERAL-EXAMPLE"
></A
><P
><B
>Example 41-1. Quoting Values In Dynamic Queries</B
></P
><P
>     When working with dynamic commands you will often have to handle escaping
     of single quotes.  The recommended method for quoting fixed text in your
     function body is dollar quoting.  (If you have legacy code that does
     not use dollar quoting, please refer to the
     overview in <A
HREF="plpgsql-development-tips.html#PLPGSQL-QUOTE-TIPS"
>Section 41.11.1</A
>, which can save you
     some effort when translating said code to a more reasonable scheme.)
    </P
><P
>     Dynamic values require careful handling since they might contain
     quote characters.
     An example using <CODE
CLASS="FUNCTION"
>format()</CODE
> (this assumes that you are
     dollar quoting the function body so quote marks need not be doubled):
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE format('UPDATE tbl SET %I = $1 '
   'WHERE key = $2', colname) USING newvalue, keyvalue;</PRE
><P>
     It is also possible to call the quoting functions directly:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE 'UPDATE tbl SET '
        || quote_ident(colname)
        || ' = '
        || quote_literal(newvalue)
        || ' WHERE key = '
        || quote_literal(keyvalue);</PRE
><P>
    </P
><P
>     This example demonstrates the use of the
     <CODE
CLASS="FUNCTION"
>quote_ident</CODE
> and
     <CODE
CLASS="FUNCTION"
>quote_literal</CODE
> functions (see <A
HREF="functions-string.html"
>Section 9.4</A
>).  For safety, expressions containing column
     or table identifiers should be passed through
     <CODE
CLASS="FUNCTION"
>quote_ident</CODE
> before insertion in a dynamic query.
     Expressions containing values that should be literal strings in the
     constructed command should be passed through <CODE
CLASS="FUNCTION"
>quote_literal</CODE
>.
     These functions take the appropriate steps to return the input text
     enclosed in double or single quotes respectively, with any embedded
     special characters properly escaped.
    </P
><P
>     Because <CODE
CLASS="FUNCTION"
>quote_literal</CODE
> is labeled
     <TT
CLASS="LITERAL"
>STRICT</TT
>, it will always return null when called with a
     null argument.  In the above example, if <TT
CLASS="LITERAL"
>newvalue</TT
> or
     <TT
CLASS="LITERAL"
>keyvalue</TT
> were null, the entire dynamic query string would
     become null, leading to an error from <TT
CLASS="COMMAND"
>EXECUTE</TT
>.
     You can avoid this problem by using the <CODE
CLASS="FUNCTION"
>quote_nullable</CODE
>
     function, which works the same as <CODE
CLASS="FUNCTION"
>quote_literal</CODE
> except that
     when called with a null argument it returns the string <TT
CLASS="LITERAL"
>NULL</TT
>.
     For example,
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE 'UPDATE tbl SET '
        || quote_ident(colname)
        || ' = '
        || quote_nullable(newvalue)
        || ' WHERE key = '
        || quote_nullable(keyvalue);</PRE
><P>
     If you are dealing with values that might be null, you should usually
     use <CODE
CLASS="FUNCTION"
>quote_nullable</CODE
> in place of <CODE
CLASS="FUNCTION"
>quote_literal</CODE
>.
    </P
><P
>     As always, care must be taken to ensure that null values in a query do
     not deliver unintended results.  For example the <TT
CLASS="LITERAL"
>WHERE</TT
> clause
</P><PRE
CLASS="PROGRAMLISTING"
>'WHERE key = ' || quote_nullable(keyvalue)</PRE
><P>
     will never succeed if <TT
CLASS="LITERAL"
>keyvalue</TT
> is null, because the
     result of using the equality operator <TT
CLASS="LITERAL"
>=</TT
> 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
</P><PRE
CLASS="PROGRAMLISTING"
>'WHERE key IS NOT DISTINCT FROM ' || quote_nullable(keyvalue)</PRE
><P>
     (At present, <TT
CLASS="LITERAL"
>IS NOT DISTINCT FROM</TT
> is handled much less
     efficiently than <TT
CLASS="LITERAL"
>=</TT
>, so don't do this unless you must.
     See <A
HREF="functions-comparison.html"
>Section 9.2</A
> for
     more information on nulls and <TT
CLASS="LITERAL"
>IS DISTINCT</TT
>.)
    </P
><P
>     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:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE 'UPDATE tbl SET '
        || quote_ident(colname)
        || ' = $$'
        || newvalue
        || '$$ WHERE key = '
        || quote_literal(keyvalue);</PRE
><P>
     because it would break if the contents of <TT
CLASS="LITERAL"
>newvalue</TT
>
     happened to contain <TT
CLASS="LITERAL"
>$$</TT
>.  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
     <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>must</I
></SPAN
> use <CODE
CLASS="FUNCTION"
>quote_literal</CODE
>,
     <CODE
CLASS="FUNCTION"
>quote_nullable</CODE
>, or <CODE
CLASS="FUNCTION"
>quote_ident</CODE
>, as appropriate.
    </P
><P
>     Dynamic SQL statements can also be safely constructed using the
     <CODE
CLASS="FUNCTION"
>format</CODE
> function (see <A
HREF="functions-string.html"
>Section 9.4</A
>). For example:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE format('UPDATE tbl SET %I = %L '
   'WHERE key = %L', colname, newvalue, keyvalue);</PRE
><P>
     <TT
CLASS="LITERAL"
>%I</TT
> is equivalent to <CODE
CLASS="FUNCTION"
>quote_ident</CODE
>, and
     <TT
CLASS="LITERAL"
>%L</TT
> is equivalent to <CODE
CLASS="FUNCTION"
>quote_nullable</CODE
>.
     The <CODE
CLASS="FUNCTION"
>format</CODE
> function can be used in conjunction with
     the <TT
CLASS="LITERAL"
>USING</TT
> clause:
</P><PRE
CLASS="PROGRAMLISTING"
>EXECUTE format('UPDATE tbl SET %I = $1 WHERE key = $2', colname)
   USING newvalue, keyvalue;</PRE
><P>
     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 <TT
CLASS="LITERAL"
>%L</TT
>.  It is also more efficient.
    </P
></DIV
><P
>     A much larger example of a dynamic command and
     <TT
CLASS="COMMAND"
>EXECUTE</TT
> can be seen in <A
HREF="plpgsql-porting.html#PLPGSQL-PORTING-EX2"
>Example 41-9</A
>, which builds and executes a
     <TT
CLASS="COMMAND"
>CREATE FUNCTION</TT
> command to define a new function.
    </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-DIAGNOSTICS"
>41.5.5. Obtaining the Result Status</A
></H2
><P
>     There are several ways to determine the effect of a command. The
     first method is to use the <TT
CLASS="COMMAND"
>GET DIAGNOSTICS</TT
>
     command, which has the form:

</P><PRE
CLASS="SYNOPSIS"
>GET [<SPAN
CLASS="OPTIONAL"
> CURRENT </SPAN
>] DIAGNOSTICS <TT
CLASS="REPLACEABLE"
><I
>variable</I
></TT
> { = | := } <TT
CLASS="REPLACEABLE"
><I
>item</I
></TT
> [<SPAN
CLASS="OPTIONAL"
> , ... </SPAN
>];</PRE
><P>

     This command allows retrieval of system status indicators.
     <TT
CLASS="LITERAL"
>CURRENT</TT
> is a noise word (but see also <TT
CLASS="COMMAND"
>GET STACKED
     DIAGNOSTICS</TT
> in <A
HREF="plpgsql-control-structures.html#PLPGSQL-EXCEPTION-DIAGNOSTICS"
>Section 41.6.6.1</A
>).
     Each <TT
CLASS="REPLACEABLE"
><I
>item</I
></TT
> is a key word identifying a status
     value to be assigned to the specified <TT
CLASS="REPLACEABLE"
><I
>variable</I
></TT
>
     (which should be of the right data type to receive it).  The currently
     available status items are shown
     in <A
HREF="plpgsql-statements.html#PLPGSQL-CURRENT-DIAGNOSTICS-VALUES"
>Table 41-1</A
>.  Colon-equal
     (<TT
CLASS="LITERAL"
>:=</TT
>) can be used instead of the SQL-standard <TT
CLASS="LITERAL"
>=</TT
>
     token.  An example:
</P><PRE
CLASS="PROGRAMLISTING"
>GET DIAGNOSTICS integer_var = ROW_COUNT;</PRE
><P>
    </P
><DIV
CLASS="TABLE"
><A
NAME="PLPGSQL-CURRENT-DIAGNOSTICS-VALUES"
></A
><P
><B
>Table 41-1. Available Diagnostics Items</B
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><THEAD
><TR
><TH
>Name</TH
><TH
>Type</TH
><TH
>Description</TH
></TR
></THEAD
><TBODY
><TR
><TD
><TT
CLASS="VARNAME"
>ROW_COUNT</TT
></TD
><TD
><TT
CLASS="TYPE"
>bigint</TT
></TD
><TD
>the number of rows processed by the most
          recent <ACRONYM
CLASS="ACRONYM"
>SQL</ACRONYM
> command</TD
></TR
><TR
><TD
><TT
CLASS="VARNAME"
>RESULT_OID</TT
></TD
><TD
><TT
CLASS="TYPE"
>oid</TT
></TD
><TD
>the OID of the last row inserted by the most
          recent <ACRONYM
CLASS="ACRONYM"
>SQL</ACRONYM
> command (only useful after
          an <TT
CLASS="COMMAND"
>INSERT</TT
> command into a table having
          OIDs)</TD
></TR
><TR
><TD
><TT
CLASS="LITERAL"
>PG_CONTEXT</TT
></TD
><TD
><TT
CLASS="TYPE"
>text</TT
></TD
><TD
>line(s) of text describing the current call stack
          (see <A
HREF="plpgsql-control-structures.html#PLPGSQL-CALL-STACK"
>Section 41.6.7</A
>)</TD
></TR
></TBODY
></TABLE
></DIV
><P
>     The second method to determine the effects of a command is to check the
     special variable named <TT
CLASS="LITERAL"
>FOUND</TT
>, which is of
     type <TT
CLASS="TYPE"
>boolean</TT
>.  <TT
CLASS="LITERAL"
>FOUND</TT
> starts out
     false within each <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> function call.
     It is set by each of the following types of statements:

         <P
></P
></P><UL
><LI
><P
>            A <TT
CLASS="COMMAND"
>SELECT INTO</TT
> statement sets
            <TT
CLASS="LITERAL"
>FOUND</TT
> true if a row is assigned, false if no
            row is returned.
           </P
></LI
><LI
><P
>            A <TT
CLASS="COMMAND"
>PERFORM</TT
> statement sets <TT
CLASS="LITERAL"
>FOUND</TT
>
            true if it produces (and discards) one or more rows, false if
            no row is produced.
           </P
></LI
><LI
><P
>            <TT
CLASS="COMMAND"
>UPDATE</TT
>, <TT
CLASS="COMMAND"
>INSERT</TT
>, and <TT
CLASS="COMMAND"
>DELETE</TT
>
            statements set <TT
CLASS="LITERAL"
>FOUND</TT
> true if at least one
            row is affected, false if no row is affected.
           </P
></LI
><LI
><P
>            A <TT
CLASS="COMMAND"
>FETCH</TT
> statement sets <TT
CLASS="LITERAL"
>FOUND</TT
>
            true if it returns a row, false if no row is returned.
           </P
></LI
><LI
><P
>            A <TT
CLASS="COMMAND"
>MOVE</TT
> statement sets <TT
CLASS="LITERAL"
>FOUND</TT
>
            true if it successfully repositions the cursor, false otherwise.
           </P
></LI
><LI
><P
>            A <TT
CLASS="COMMAND"
>FOR</TT
> or <TT
CLASS="COMMAND"
>FOREACH</TT
> statement sets
            <TT
CLASS="LITERAL"
>FOUND</TT
> true
            if it iterates one or more times, else false.
            <TT
CLASS="LITERAL"
>FOUND</TT
> is set this way when the
            loop exits; inside the execution of the loop,
            <TT
CLASS="LITERAL"
>FOUND</TT
> is not modified by the
            loop statement, although it might be changed by the
            execution of other statements within the loop body.
           </P
></LI
><LI
><P
>            <TT
CLASS="COMMAND"
>RETURN QUERY</TT
> and <TT
CLASS="COMMAND"
>RETURN QUERY
            EXECUTE</TT
> statements set <TT
CLASS="LITERAL"
>FOUND</TT
>
            true if the query returns at least one row, false if no row
            is returned.
           </P
></LI
></UL
><P>

     Other <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> statements do not change
     the state of <TT
CLASS="LITERAL"
>FOUND</TT
>.
     Note in particular that <TT
CLASS="COMMAND"
>EXECUTE</TT
>
     changes the output of <TT
CLASS="COMMAND"
>GET DIAGNOSTICS</TT
>, but
     does not change <TT
CLASS="LITERAL"
>FOUND</TT
>.
    </P
><P
>     <TT
CLASS="LITERAL"
>FOUND</TT
> is a local variable within each
     <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> function; any changes to it
     affect only the current function.
    </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLPGSQL-STATEMENTS-NULL"
>41.5.6. Doing Nothing At All</A
></H2
><P
>     Sometimes a placeholder statement that does nothing is useful.
     For example, it can indicate that one arm of an if/then/else
     chain is deliberately empty.  For this purpose, use the
     <TT
CLASS="COMMAND"
>NULL</TT
> statement:

</P><PRE
CLASS="SYNOPSIS"
>NULL;</PRE
><P>
    </P
><P
>     For example, the following two fragments of code are equivalent:
</P><PRE
CLASS="PROGRAMLISTING"
>BEGIN
    y := x / 0;
EXCEPTION
    WHEN division_by_zero THEN
        NULL;  -- ignore the error
END;</PRE
><P>

</P><PRE
CLASS="PROGRAMLISTING"
>BEGIN
    y := x / 0;
EXCEPTION
    WHEN division_by_zero THEN  -- ignore the error
END;</PRE
><P>
     Which is preferable is a matter of taste.
    </P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>      In Oracle's PL/SQL, empty statement lists are not allowed, and so
      <TT
CLASS="COMMAND"
>NULL</TT
> statements are <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>required</I
></SPAN
> for situations
      such as this.  <SPAN
CLASS="APPLICATION"
>PL/pgSQL</SPAN
> allows you to
      just write nothing, instead.
     </P
></BLOCKQUOTE
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="plpgsql-expressions.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="plpgsql-control-structures.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Expressions</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="plpgsql.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Control Structures</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>

Perl :: Catalyst :: PostgreSQL :: RPM Valid HTML 4.01 Transitional