If you execute the above function, it will reference the OID for
my_function() in the query plan produced for
- the PERFORM statement. Later, if you
+ the PERFORM statement. Later, if you
drop and re-create my_function(), then
populate() will not be able to find
my_function() anymore. You would then have to
same tables and fields on every execution; that is, you cannot use
a parameter as the name of a table or field in a query. To get
around this restriction, you can construct dynamic queries using
- the
PL/pgSQL EXECUTE statement --- at
- the price of constructing a new query plan on every execution.
+ statement --- at the price of constructing a new query plan on
+ every execution.
- The
PL/pgSQL EXECUTE statement is not
- related to the EXECUTE statement supported by the
+ EXECUTE statement is not related to the
+ EXECUTE statement supported by the
PostgreSQL backend. The backend
- EXECUTE statement cannot be used within
PL/pgSQL functions (and- is not needed).
+ EXECUTE statement cannot be used within
+
PL/pgSQL functions (and is not needed).
- That means that your client application must send each
- query to the database server, wait for it to process it,
- receive the results, do some computation, then send
- other queries to the server. All this incurs inter-process communication
- and may also incur network
- overhead if your client is on a different machine than
- the database server.
+ That means that your client application must send each query to
+ the database server, wait for it to process it, receive the
+ results, do some computation, then send other queries to the
+ server. All this incurs inter-process communication and may also
+ incur network overhead if your client is on a different machine
+ than the database server.
The mutable nature of record variables presents a problem in this
- connection. When fields of a record variable are used in expressions or
- statements, the data types of the
- fields must not change between calls of one and the same expression,
- since the expression will be planned using the data type that is present
- when the expression is first reached.
- Keep this in mind when writing trigger procedures that handle events
- for more than one table. (EXECUTE can be used to get around this
- problem when necessary.)
+ connection. When fields of a record variable are used in
+ expressions or statements, the data types of the fields must not
+ change between calls of one and the same expression, since the
+ expression will be planned using the data type that is present
+ when the expression is first reached. Keep this in mind when
+ writing trigger procedures that handle events for more than one
+ table. (EXECUTE can be used to get around
+ this problem when necessary.)
Executing an expression or query with no result
- Sometimes one wishes to evaluate an expression or query but discard
- the result (typically because one is calling a function that has
- useful side-effects but no useful result value). To do this in
-
PL/pgSQL, use the PERFORM statement:
+ Sometimes one wishes to evaluate an expression or query but
+ discard the result (typically because one is calling a function
+ that has useful side-effects but no useful result value). To do
+ this in
PL/pgSQL, use the
+ PERFORM statement:
PERFORM query;
- One might expect that SELECT with no INTO clause would accomplish
- this result, but at present the only accepted way to do it is PERFORM.
-
-
+ One might expect that SELECT with no INTO
+ clause would accomplish this result, but at present the only
+ accepted way to do it is PERFORM.
+
+
An example:
Executing dynamic queries
- Oftentimes you will want to generate dynamic queries inside
- your
PL/pgSQL functions, that is,
- queries that will involve different tables or different data types
-
each time they are executed.
PL/pgSQL's
+ Oftentimes you will want to generate dynamic queries inside your
+
PL/pgSQL functions, that is, queries
+ that will involve different tables or different data types each
+ time they are executed.
PL/pgSQL's
normal attempts to cache plans for queries will not work in such
- scenarios. To handle this sort of problem, the EXECUTE statement
- is provided:
+ scenarios. To handle this sort of problem, the
+ EXECUTE statement is provided:
EXECUTE query-string;
Unlike all other queries in
PL/pgSQL, a- query run by an EXECUTE statement is
- not prepared and saved just once during the life of the server.
- Instead, the query is prepared each
- time the statement is run. The
- query-string can be dynamically
- created within the procedure to perform actions on variable
- tables and fields.
+ query run by an
+ EXECUTE statement is not prepared and saved
+ just once during the life of the server. Instead, the
+ query is prepared each time the
+ statement is run. The query-string can
+ be dynamically created within the procedure to perform actions on
+ variable tables and fields.
- The results from SELECT queries are discarded by EXECUTE, and
- SELECT INTO is not currently supported within EXECUTE. So, the
- only way to extract a result from a dynamically-created SELECT is
- to use the FOR-IN-EXECUTE form described later.
+ The results from SELECT queries are discarded
+ by EXECUTE, and SELECT INTO
+ is not currently supported within EXECUTE.
+ So, the only way to extract a result from a dynamically-created
+ SELECT is to use the FOR-IN-EXECUTE form
+ described later.
- Here is a much larger example of a dynamic query and EXECUTE:
+ Here is a much larger example of a dynamic query and
+ EXECUTE:
CREATE FUNCTION cs_update_referrer_type_proc() RETURNS INTEGER AS '
DECLARE
RETURN expression;
- RETURN with an expression is used to return from a
-
PL/pgSQL function that does not return a set.- The function terminates and the value of
+ RETURN with an expression is used to return
+ from a
PL/pgSQL function that does not return a+ set. The function terminates and the value of
expression is returned to the caller.
- The return value of a function cannot be left undefined. If control
- reaches the end of the top-level block of
- the function without hitting a RETURN statement, a run-time error
- will occur.
+ The return value of a function cannot be left undefined. If
+ control reaches the end of the top-level block of the function
+ without hitting a RETURN statement, a run-time
+ error will occur.
When a
PL/pgSQL function is declared to return SETOF sometype, the procedure
to follow is slightly different. In that case, the individual
- items to return are specified in RETURN NEXT commands, and then a
- final RETURN command with no arguments is used to indicate that
- the function has finished executing. RETURN NEXT can be used with
- both scalar and composite data types; in the later case, an
- entire "table" of results will be returned. Functions that use
- RETURN NEXT should be called in the following fashion:
+ items to return are specified in RETURN NEXT
+ commands, and then a final RETURN command with
+ no arguments is used to indicate that the function has finished
+ executing. RETURN NEXT can be used with both
+ scalar and composite data types; in the later case, an entire
+ "table" of results will be returned. Functions that use
+ RETURN NEXT should be called in the following
+ fashion:
SELECT * FROM some_func();
RETURN NEXT expression;
- RETURN NEXT does not actually return from the function; it simply
- saves away the value of the expression (or record or row variable,
- as appropriate for the data type being returned).
- Execution then continues with the next statement in the
-
PL/pgSQL function. As successive RETURN NEXT- commands are executed, the result set is built up. A final
- RETURN, which need have no argument, causes control to exit
- the function.
+ RETURN NEXT does not actually return from the
+ function; it simply saves away the value of the expression (or
+ record or row variable, as appropriate for the data type being
+ returned). Execution then continues with the next statement in
+ the
PL/pgSQL function. As successive+ RETURN NEXT commands are executed, the result
+ set is built up. A final RETURN, which need
+ have no argument, causes control to exit the function.
- The current implementation of RETURN NEXT for
+ The current implementation of RETURN NEXT for
PL/pgSQL stores the entire result set before
returning from the function, as discussed above. That means that
if a
PL/pgSQL function produces a very large result set, statements
END LOOP;
- This is like the previous form, except that the source SELECT
- statement is specified as a string expression, which is evaluated
- and re-planned on each entry to the FOR loop. This allows the
- programmer to choose the speed of a pre-planned query or the
- flexibility of a dynamic query, just as with a plain EXECUTE
- statement.
+ This is like the previous form, except that the source
+ SELECT statement is specified as a string
+ expression, which is evaluated and re-planned on each entry to
+ the FOR loop. This allows the programmer to choose the speed of
+ a pre-planned query or the flexibility of a dynamic query, just
+ as with a plain EXECUTE statement.
OPEN FOR EXECUTE
OPEN unbound-cursor FOR EXECUTE query-string;
- The cursor variable is opened and given the specified query
- to execute. The cursor cannot be open already, and it must
- have been declared as an unbound cursor (that is, as a simple
- refcursor variable). The query is specified as a
- string expression in the same way as in the EXECUTE command.
- As usual, this gives flexibility so the query can vary
- from one run to the next.
+ The cursor variable is opened and given the specified query to
+ execute. The cursor cannot be open already, and it must have been
+ declared as an unbound cursor (that is, as a simple
+ refcursor variable). The query is specified as a string
+ expression in the same way as in the EXECUTE
+ command. As usual, this gives flexibility so the query can vary
+ from one run to the next.
OPEN curs1 FOR EXECUTE ''SELECT * FROM '' || quote_ident($1);
Opening a bound cursor
OPEN bound-cursor ( argument_values ) ;
- This form of OPEN is used to open a cursor variable whose query
- was bound to it when it was declared.
- The cursor cannot be open already. A list of actual argument
- value expressions must appear if and only if the cursor was
- declared to take arguments. These values will be substituted
- in the query.
- The query plan for a bound cursor is always considered
- cacheable --- there is no equivalent of EXECUTE in this case.
+ This form of OPEN is used to open a cursor
+ variable whose query was bound to it when it was declared. The
+ cursor cannot be open already. A list of actual argument value
+ expressions must appear if and only if the cursor was declared to
+ take arguments. These values will be substituted in the query.
+ The query plan for a bound cursor is always considered cacheable
+ --- there is no equivalent of EXECUTE in this case.
OPEN curs2;
FETCH
FETCH cursor INTO target;
- FETCH retrieves the next row from the cursor into a target,
- which may be a row variable, a record variable, or a comma-separated
- list of simple variables, just like SELECT INTO. As with
- SELECT INTO, the special variable FOUND may be
- checked to see whether a row was obtained or not.
+ FETCH retrieves the next row from the
+ cursor into a target, which may be a row variable, a record
+ variable, or a comma-separated list of simple variables, just like
+ SELECT INTO. As with SELECT
+ INTO, the special variable FOUND may
+ be checked to see whether a row was obtained or not.
FETCH curs1 INTO rowvar;
* procedural language
*
* IDENTIFICATION
- * $Header: /cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v 1.65 2002/10/19 22:10:58 tgl Exp $
+ * $Header: /cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v 1.66 2002/11/10 00:35:58 momjian Exp $
*
* This software is copyrighted by Jan Wieck - Hamburg.
*
PLpgSQL_stmt * stmt);
static int exec_stmt_assign(PLpgSQL_execstate * estate,
PLpgSQL_stmt_assign * stmt);
+static int exec_stmt_perform(PLpgSQL_execstate * estate,
+ PLpgSQL_stmt_perform * stmt);
static int exec_stmt_getdiag(PLpgSQL_execstate * estate,
PLpgSQL_stmt_getdiag * stmt);
static int exec_stmt_if(PLpgSQL_execstate * estate,
rc = exec_stmt_assign(estate, (PLpgSQL_stmt_assign *) stmt);
break;
+ case PLPGSQL_STMT_PERFORM:
+ rc = exec_stmt_perform(estate, (PLpgSQL_stmt_perform *) stmt);
+ break;
+
case PLPGSQL_STMT_GETDIAG:
rc = exec_stmt_getdiag(estate, (PLpgSQL_stmt_getdiag *) stmt);
break;
/* ----------
* exec_stmt_assign Evaluate an expression and
* put the result into a variable.
- *
- * For no very good reason, this is also used for PERFORM statements.
* ----------
*/
static int
exec_stmt_assign(PLpgSQL_execstate * estate, PLpgSQL_stmt_assign * stmt)
{
- PLpgSQL_expr *expr = stmt->expr;
+ Assert(stmt->varno >= 0);
- if (stmt->varno >= 0)
- exec_assign_expr(estate, estate->datums[stmt->varno], expr);
- else
- {
- /*
- * PERFORM: evaluate query and discard result (but set FOUND
- * depending on whether at least one row was returned).
- *
- * This cannot share code with the assignment case since we do not
- * wish to constrain the discarded result to be only one
- * row/column.
- */
- int rc;
+ exec_assign_expr(estate, estate->datums[stmt->varno], stmt->expr);
- /*
- * If not already done create a plan for this expression
- */
- if (expr->plan == NULL)
- exec_prepare_plan(estate, expr);
+ return PLPGSQL_RC_OK;
+}
- rc = exec_run_select(estate, expr, 0, NULL);
- if (rc != SPI_OK_SELECT)
- elog(ERROR, "query \"%s\" didn't return data", expr->query);
+/* ----------
+ * exec_stmt_perform Evaluate query and discard result (but set
+ * FOUND depending on whether at least one row
+ * was returned).
+ * ----------
+ */
+static int
+exec_stmt_perform(PLpgSQL_execstate * estate, PLpgSQL_stmt_perform * stmt)
+{
+ PLpgSQL_expr *expr = stmt->expr;
+ int rc;
- exec_set_found(estate, (estate->eval_processed != 0));
+ /*
+ * If not already done create a plan for this expression
+ */
+ if (expr->plan == NULL)
+ exec_prepare_plan(estate, expr);
+
+ rc = exec_run_select(estate, expr, 0, NULL);
+ if (rc != SPI_OK_SELECT)
+ elog(ERROR, "query \"%s\" didn't return data", expr->query);
- exec_eval_cleanup(estate);
- }
+ exec_set_found(estate, (estate->eval_processed != 0));
+
+ exec_eval_cleanup(estate);
return PLPGSQL_RC_OK;
}
return PLPGSQL_RC_RETURN;
}
-/*
- * Notes:
- * - the tuple store must be created in a sufficiently long-lived
- * memory context, as the same store must be used within the executor
- * after the PL/PgSQL call returns. At present, the code uses
- * TopTransactionContext.
+/* ----------
+ * exec_stmt_return_next Evaluate an expression and add it to the
+ * list of tuples returned by the current
+ * SRF.
+ * ----------
*/
static int
exec_stmt_return_next(PLpgSQL_execstate * estate,
estate->rettupdesc = rsi->expectedDesc;
}
-
/* ----------
* exec_stmt_raise Build a message and throw it with
* elog()
projects / postgresql.git / commitdiff