rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/pl/plpgsql/src/pl_exec.c

5459 lines
138 KiB
C
Raw Normal View History

Remove Jan Wieck's name from copyrights, and put in standard boilerplate, with approval of author.
2006-03-09 22:29:38 +01:00
/*-------------------------------------------------------------------------
*
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* pl_exec.c - Executor for the PL/pgSQL
* procedural language
*
Update copyrights in source tree to 2008.
2008-01-01 20:46:01 +01:00
* Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
Remove Jan Wieck's name from copyrights, and put in standard boilerplate, with approval of author.
2006-03-09 22:29:38 +01:00
* Portions Copyright (c) 1994, Regents of the University of California
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*
*
Remove Jan Wieck's name from copyrights, and put in standard boilerplate, with approval of author.
2006-03-09 22:29:38 +01:00
* IDENTIFICATION
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
* $PostgreSQL: pgsql/src/pl/plpgsql/src/pl_exec.c,v 1.223 2008/11/02 01:45:28 tgl Exp $
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*
Remove Jan Wieck's name from copyrights, and put in standard boilerplate, with approval of author.
2006-03-09 22:29:38 +01:00
*-------------------------------------------------------------------------
*/
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
#include "plpgsql.h"
Be careful to include postgres.h *before* any system headers, to ensure that the right flavors of largefile-related definitions are seen. Most of these changes are probably unnecessary, but better safe than sorry.
2002-09-05 02:43:07 +02:00
#include <ctype.h>
Allow include files to compile own their own. Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
2006-07-13 18:49:20 +02:00
#include "access/transam.h"
First stage of reclaiming memory in executor by resetting short-term memory contexts. Currently, only leaks in expressions executed as quals or projections are handled. Clean up some old dead cruft in executor while at it --- unused fields in state nodes, that sort of thing.
2000-07-12 04:37:39 +02:00
#include "catalog/pg_proc.h"
#include "catalog/pg_type.h"
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
#include "executor/spi_priv.h"
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
#include "funcapi.h"
Move exprType(), exprTypmod(), expression_tree_walker(), and related routines into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside the backend. There's probably more that should be done along this line, but this is a start anyway.
2008-08-26 00:42:34 +02:00
#include "nodes/nodeFuncs.h"
Fix bugs in plpgsql and ecpg caused by assuming that isspace() would only return true for exactly the characters treated as whitespace by their flex scanners. Per report from Victor Snezhko and subsequent investigation. Also fix a passel of unsafe usages of <ctype.h> functions, that is, ye olde char-vs-unsigned-char issue. I won't miss <ctype.h> when we are finally able to stop using it.
2006-09-22 23:39:58 +02:00
#include "parser/scansup.h"
Change elog(ERROR) to get back to main loop via a plain sigsetjmp, instead of doing a kill(self, SIGQUIT) and expecting the signal handler to do it. Also, clean up inconsistent definitions of the sigjmp buffer in the several files that already referenced it.
1999-04-20 04:19:59 +02:00
#include "tcop/tcopprot.h"
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
#include "utils/array.h"
First stage of reclaiming memory in executor by resetting short-term memory contexts. Currently, only leaks in expressions executed as quals or projections are handled. Clean up some old dead cruft in executor while at it --- unused fields in state nodes, that sort of thing.
2000-07-12 04:37:39 +02:00
#include "utils/builtins.h"
#include "utils/lsyscache.h"
For some reason access/tupmacs.h has been #including utils/memutils.h, which is neither needed by nor related to that header. Remove the bogus inclusion and instead include the header in those C files that actually need it. Also fix unnecessary inclusions and bad inclusion order in tsearch2 files.
2005-05-06 19:24:55 +02:00
#include "utils/memutils.h"
Rename snapmgmt.c/h to snapmgr.c/h, for consistency with other files. Per complaint from Tom Lane.
2008-03-26 19:48:59 +01:00
#include "utils/snapmgr.h"
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
#include "utils/typcache.h"
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
pgindent run.
2003-08-04 02:43:34 +02:00
static const char *const raise_skip_msg = "RAISE";
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
typedef struct
{
int nargs; /* number of arguments */
Oid *types; /* types of arguments */
Datum *values; /* evaluated argument values */
char *nulls; /* null markers (' '/'n' style) */
bool *freevals; /* which arguments are pfree-able */
} PreparedParamsData;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
/*
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* All plpgsql function executions within a single transaction share the same
* executor EState for evaluating "simple" expressions. Each function call
* creates its own "eval_econtext" ExprContext within this estate for
* per-evaluation workspace. eval_econtext is freed at normal function exit,
* and the EState is freed at transaction end (in case of error, we assume
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* that the abort mechanisms clean it all up). In order to be sure
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* ExprContext callbacks are handled properly, each subtransaction has to have
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* its own such EState; hence we need a stack. We use a simple counter to
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* distinguish different instantiations of the EState, so that we can tell
* whether we have a current copy of a prepared expression.
*
* This arrangement is a bit tedious to maintain, but it's worth the trouble
* so that we don't have to re-prepare simple expressions on each trip through
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* a function. (We assume the case to optimize is many repetitions of a
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* function within a transaction.)
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*/
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
typedef struct SimpleEstateStackEntry
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
EState *xact_eval_estate; /* EState for current xact level */
long int xact_estate_simple_id; /* ID for xact_eval_estate */
SubTransactionId xact_subxid; /* ID for current subxact */
struct SimpleEstateStackEntry *next; /* next stack entry up */
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
} SimpleEstateStackEntry;
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
static SimpleEstateStackEntry *simple_estate_stack = NULL;
static long int simple_estate_id_counter = 0;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/************************************************************
* Local function forward declarations
************************************************************/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
static void plpgsql_exec_error_callback(void *arg);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static PLpgSQL_datum *copy_plpgsql_datum(PLpgSQL_datum *datum);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_stmt_block(PLpgSQL_execstate *estate,
PLpgSQL_stmt_block *block);
static int exec_stmts(PLpgSQL_execstate *estate,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
List *stmts);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_stmt(PLpgSQL_execstate *estate,
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,
PLpgSQL_stmt_if *stmt);
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
static int exec_stmt_case(PLpgSQL_execstate *estate,
PLpgSQL_stmt_case *stmt);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_stmt_loop(PLpgSQL_execstate *estate,
PLpgSQL_stmt_loop *stmt);
static int exec_stmt_while(PLpgSQL_execstate *estate,
PLpgSQL_stmt_while *stmt);
static int exec_stmt_fori(PLpgSQL_execstate *estate,
PLpgSQL_stmt_fori *stmt);
static int exec_stmt_fors(PLpgSQL_execstate *estate,
PLpgSQL_stmt_fors *stmt);
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
static int exec_stmt_forc(PLpgSQL_execstate *estate,
PLpgSQL_stmt_forc *stmt);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_stmt_open(PLpgSQL_execstate *estate,
PLpgSQL_stmt_open *stmt);
static int exec_stmt_fetch(PLpgSQL_execstate *estate,
PLpgSQL_stmt_fetch *stmt);
static int exec_stmt_close(PLpgSQL_execstate *estate,
PLpgSQL_stmt_close *stmt);
static int exec_stmt_exit(PLpgSQL_execstate *estate,
PLpgSQL_stmt_exit *stmt);
static int exec_stmt_return(PLpgSQL_execstate *estate,
PLpgSQL_stmt_return *stmt);
static int exec_stmt_return_next(PLpgSQL_execstate *estate,
PLpgSQL_stmt_return_next *stmt);
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
static int exec_stmt_return_query(PLpgSQL_execstate *estate,
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
PLpgSQL_stmt_return_query *stmt);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_stmt_raise(PLpgSQL_execstate *estate,
PLpgSQL_stmt_raise *stmt);
static int exec_stmt_execsql(PLpgSQL_execstate *estate,
PLpgSQL_stmt_execsql *stmt);
static int exec_stmt_dynexecute(PLpgSQL_execstate *estate,
PLpgSQL_stmt_dynexecute *stmt);
static int exec_stmt_dynfors(PLpgSQL_execstate *estate,
PLpgSQL_stmt_dynfors *stmt);
static void plpgsql_estate_setup(PLpgSQL_execstate *estate,
PLpgSQL_function *func,
pgindent run.
2002-09-04 22:31:48 +02:00
ReturnSetInfo *rsi);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_eval_cleanup(PLpgSQL_execstate *estate);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_prepare_plan(PLpgSQL_execstate *estate,
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
PLpgSQL_expr *expr, int cursorOptions);
pgindent run over code.
1999-05-25 18:15:34 +02:00
static bool exec_simple_check_node(Node *node);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_simple_check_plan(PLpgSQL_expr *expr);
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
static bool exec_eval_simple_expr(PLpgSQL_execstate *estate,
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
PLpgSQL_expr *expr,
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
Datum *result,
pgindent run over code.
1999-05-25 18:15:34 +02:00
bool *isNull,
Oid *rettype);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_assign_expr(PLpgSQL_execstate *estate,
PLpgSQL_datum *target,
PLpgSQL_expr *expr);
static void exec_assign_value(PLpgSQL_execstate *estate,
PLpgSQL_datum *target,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum value, Oid valtype, bool *isNull);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_eval_datum(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum,
pgindent run.
2003-08-04 02:43:34 +02:00
Oid expectedtypeid,
Oid *typeid,
Datum *value,
bool *isnull);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_eval_integer(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
bool *isNull);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static bool exec_eval_boolean(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
bool *isNull);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static Datum exec_eval_expr(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
bool *isNull,
Oid *rettype);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static int exec_run_select(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, long maxtuples, Portal *portalP);
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
static int exec_for_query(PLpgSQL_execstate *estate, PLpgSQL_stmt_forq *stmt,
Portal portal, bool prefetch_ok);
static void eval_expr_params(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, Datum **p_values, char **p_nulls);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_move_row(PLpgSQL_execstate *estate,
PLpgSQL_rec *rec,
PLpgSQL_row *row,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
HeapTuple tup, TupleDesc tupdesc);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static HeapTuple make_tuple_from_row(PLpgSQL_execstate *estate,
PLpgSQL_row *row,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
TupleDesc tupdesc);
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
static char *convert_value_to_string(Datum value, Oid valtype);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static Datum exec_cast_value(Datum value, Oid valtype,
Oid reqtype,
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
FmgrInfo *reqinput,
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid reqtypioparam,
Fix a passel of problems with incorrect calls to typinput and typoutput functions, which would lead to trouble with datatypes that paid attention to the typelem or typmod parameters to these functions. In particular, incorrect code in pg_aggregate.c explains the platform-specific failures that have been reported in NUMERIC avg().
2000-01-15 23:43:25 +01:00
int32 reqtypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
bool isnull);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
static Datum exec_simple_cast_value(Datum value, Oid valtype,
pgindent run.
2003-08-04 02:43:34 +02:00
Oid reqtype, int32 reqtypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
bool isnull);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
static void validate_tupdesc_compat(TupleDesc expected, TupleDesc returned,
const char *msg);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
static void free_var(PLpgSQL_var *var);
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
static void assign_text_var(PLpgSQL_var *var, const char *str);
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
static PreparedParamsData *exec_eval_using_params(PLpgSQL_execstate *estate,
List *params);
static void free_params_data(PreparedParamsData *ppd);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
static Portal exec_dynquery_with_params(PLpgSQL_execstate *estate,
PLpgSQL_expr *query, List *params);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* plpgsql_exec_function Called by the call handler for
* function execution.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
plpgsql_exec_function(PLpgSQL_function *func, FunctionCallInfo fcinfo)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_execstate estate;
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
ErrorContextCallback plerrcontext;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int i;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
int rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Setup the execution state
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
plpgsql_estate_setup(&estate, func, (ReturnSetInfo *) fcinfo->resultinfo);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Setup error traceback support for ereport()
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
plerrcontext.callback = plpgsql_exec_error_callback;
plerrcontext.arg = &estate;
plerrcontext.previous = error_context_stack;
error_context_stack = &plerrcontext;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Make local execution copies of all the datums
*/
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = gettext_noop("during initialization of execution state");
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
for (i = 0; i < estate.ndatums; i++)
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
estate.datums[i] = copy_plpgsql_datum(func->datums[i]);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
* Store the actual call argument values into the appropriate variables
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = gettext_noop("while storing call arguments into local variables");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
for (i = 0; i < func->fn_nargs; i++)
{
int n = func->fn_argvarnos[i];
switch (estate.datums[n]->dtype)
{
case PLPGSQL_DTYPE_VAR:
{
PLpgSQL_var *var = (PLpgSQL_var *) estate.datums[n];
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
var->value = fcinfo->arg[i];
var->isnull = fcinfo->argnull[i];
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
var->freeval = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
break;
case PLPGSQL_DTYPE_ROW:
{
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
PLpgSQL_row *row = (PLpgSQL_row *) estate.datums[n];
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Don't crash when a rowtype argument to a plpgsql function is NULL. Per report from Chris Campbell.
2004-02-24 02:44:33 +01:00
if (!fcinfo->argnull[i])
{
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
HeapTupleHeader td;
Oid tupType;
int32 tupTypmod;
TupleDesc tupdesc;
HeapTupleData tmptup;
td = DatumGetHeapTupleHeader(fcinfo->arg[i]);
/* Extract rowtype info and find a tupdesc */
tupType = HeapTupleHeaderGetTypeId(td);
tupTypmod = HeapTupleHeaderGetTypMod(td);
tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
/* Build a temporary HeapTuple control structure */
tmptup.t_len = HeapTupleHeaderGetDatumLength(td);
ItemPointerSetInvalid(&(tmptup.t_self));
tmptup.t_tableOid = InvalidOid;
tmptup.t_data = td;
exec_move_row(&estate, NULL, row, &tmptup, tupdesc);
Fix problems with cached tuple descriptors disappearing while still in use by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
2006-06-16 20:42:24 +02:00
ReleaseTupleDesc(tupdesc);
Don't crash when a rowtype argument to a plpgsql function is NULL. Per report from Chris Campbell.
2004-02-24 02:44:33 +01:00
}
else
{
/* If arg is null, treat it as an empty row */
exec_move_row(&estate, NULL, row, NULL, NULL);
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
break;
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized dtype: %d", func->datums[i]->dtype);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate.err_text = gettext_noop("during function entry");
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Set the magic variable FOUND to false
*/
exec_set_found(&estate, false);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/*
* Let the instrumentation plugin peek at this function
*/
if (*plugin_ptr && (*plugin_ptr)->func_beg)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->func_beg) (&estate, func);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Now call the toplevel block of statements
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate.err_text = NULL;
estate.err_stmt = (PLpgSQL_stmt *) (func->action);
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
rc = exec_stmt_block(&estate, func->action);
if (rc != PLPGSQL_RC_RETURN)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate.err_stmt = NULL;
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = NULL;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
/*
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
* Provide a more helpful message if a CONTINUE or RAISE has been used
* outside the context it can work in.
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
*/
if (rc == PLPGSQL_RC_CONTINUE)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("CONTINUE cannot be used outside a loop")));
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
else if (rc == PLPGSQL_RC_RERAISE)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE without parameters cannot be used outside an exception handler")));
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
else
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_S_R_E_FUNCTION_EXECUTED_NO_RETURN_STATEMENT),
errmsg("control reached end of function without RETURN")));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* We got a return value - process it
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate.err_stmt = NULL;
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = gettext_noop("while casting return value to function's return type");
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
First round of changes for new fmgr interface. fmgr itself and the key call sites are changed, but most called functions are still oldstyle. An exception is that the PL managers are updated (so, for example, NULL handling now behaves as expected in plperl and plpgsql functions). NOTE initdb is forced due to added column in pg_proc.
2000-05-28 19:56:29 +02:00
fcinfo->isnull = estate.retisnull;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (estate.retisset)
{
ReturnSetInfo *rsi = estate.rsi;
/* Check caller can handle a set result */
if (!rsi || !IsA(rsi, ReturnSetInfo) ||
(rsi->allowedModes & SFRM_Materialize) == 0)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("set-valued function called in context that cannot accept a set")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
rsi->returnMode = SFRM_Materialize;
/* If we produced any tuples, send back the result */
if (estate.tuple_store)
{
rsi->setResult = estate.tuple_store;
if (estate.rettupdesc)
Revise tuplestore and nodeMaterial so that we don't have to read the entire contents of the subplan into the tuplestore before we can return any tuples. Instead, the tuplestore holds what we've already read, and we fetch additional rows from the subplan as needed. Random access to the previously-read rows works with the tuplestore, and doesn't affect the state of the partially-read subplan. This is a step towards fixing the problems with cursors over complex queries --- we don't want to stick in Materialize nodes if they'll prevent quick startup for a cursor.
2003-03-09 03:19:13 +01:00
{
MemoryContext oldcxt;
oldcxt = MemoryContextSwitchTo(estate.tuple_store_cxt);
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
rsi->setDesc = CreateTupleDescCopy(estate.rettupdesc);
Revise tuplestore and nodeMaterial so that we don't have to read the entire contents of the subplan into the tuplestore before we can return any tuples. Instead, the tuplestore holds what we've already read, and we fetch additional rows from the subplan as needed. Random access to the previously-read rows works with the tuplestore, and doesn't affect the state of the partially-read subplan. This is a step towards fixing the problems with cursors over complex queries --- we don't want to stick in Materialize nodes if they'll prevent quick startup for a cursor.
2003-03-09 03:19:13 +01:00
MemoryContextSwitchTo(oldcxt);
}
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
}
estate.retval = (Datum) 0;
fcinfo->isnull = true;
}
else if (!estate.retisnull)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
if (estate.retistuple)
{
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* We have to check that the returned tuple actually matches the
* expected result type. XXX would be better to cache the tupdesc
* instead of repeating get_call_result_type()
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
*/
TupleDesc tupdesc;
switch (get_call_result_type(fcinfo, NULL, &tupdesc))
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
validate_tupdesc_compat(tupdesc, estate.rettupdesc,
gettext_noop("returned record type does "
"not match expected record type"));
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
break;
case TYPEFUNC_RECORD:
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
/*
* Failed to determine actual type of RECORD. We could
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* raise an error here, but what this means in practice is
* that the caller is expecting any old generic rowtype,
* so we don't really need to be restrictive. Pass back
* the generated result type, instead.
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
*/
tupdesc = estate.rettupdesc;
if (tupdesc == NULL) /* shouldn't happen */
elog(ERROR, "return type must be a row type");
break;
default:
/* shouldn't get here if retistuple is true ... */
elog(ERROR, "return type must be a row type");
break;
}
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Copy tuple to upper executor memory, as a tuple Datum. Make
* sure it is labeled with the caller-supplied tuple type.
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
*/
Replace TupleTableSlot convention for whole-row variables and function results with tuples as ordinary varlena Datums. This commit does not in itself do much for us, except eliminate the horrid memory leak associated with evaluation of whole-row variables. However, it lays the groundwork for allowing composite types as table columns, and perhaps some other useful features as well. Per my proposal of a few days ago.
2004-04-01 23:28:47 +02:00
estate.retval =
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
PointerGetDatum(SPI_returntuple((HeapTuple)DatumGetPointer(estate.retval),
Add checks to verify that a plpgsql function returning a rowtype is actually returning the rowtype it's supposed to return. Per reports from David Niblett and Michael Fuhr.
2006-01-03 23:48:10 +01:00
tupdesc));
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
}
else
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
/* Cast value to proper type */
estate.retval = exec_cast_value(estate.retval, estate.rettype,
func->fn_rettype,
&(func->fn_retinput),
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
func->fn_rettypioparam,
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
-1,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
fcinfo->isnull);
Fix indenting for 'extern "C"' cases.
2001-11-08 21:37:52 +01:00
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
/*
Fix a few typos in comments.
2004-11-30 04:50:29 +01:00
* If the function's return type isn't by value, copy the value
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
* into upper executor memory context.
*/
if (!fcinfo->isnull && !func->fn_retbyval)
{
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
2002-08-24 17:00:47 +02:00
Size len;
void *tmp;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
2002-08-24 17:00:47 +02:00
len = datumGetSize(estate.retval, false, func->fn_rettyplen);
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
tmp = SPI_palloc(len);
The cstring datatype can now be copied, passed around, etc. The typlen value '-2' is used to indicate a variable-width type whose width is computed as strlen(datum)+1. Everything that looks at typlen is updated except for array support, which Joe Conway is working on; at the moment it wouldn't work to try to create an array of cstring.
2002-08-24 17:00:47 +02:00
memcpy(tmp, DatumGetPointer(estate.retval), len);
estate.retval = PointerGetDatum(tmp);
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate.err_text = gettext_noop("during function exit");
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/*
* Let the instrumentation plugin peek at this function
*/
if (*plugin_ptr && (*plugin_ptr)->func_end)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->func_end) (&estate, func);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* Clean up any leftover temporary memory */
Minor code clarity improvement: AFAICS, estate.eval_econtext must be non-NULL during the guts of plpgsql_exec_trigger() and plpgsql_exec_function(). Therefore, we can remove the NULL check, per discussion on -patches.
2006-01-10 19:50:43 +01:00
FreeExprContext(estate.eval_econtext);
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
estate.eval_econtext = NULL;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(&estate);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Pop the error context stack
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
error_context_stack = plerrcontext.previous;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Fix a few typos in comments.
2004-11-30 04:50:29 +01:00
* Return the function's result
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
return estate.retval;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* plpgsql_exec_trigger Called by the call handler for
* trigger execution.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
HeapTuple
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
plpgsql_exec_trigger(PLpgSQL_function *func,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
TriggerData *trigdata)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_execstate estate;
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
ErrorContextCallback plerrcontext;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int i;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
int rc;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_var *var;
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
PLpgSQL_rec *rec_new,
pgindent run.
2003-08-04 02:43:34 +02:00
*rec_old;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
HeapTuple rettup;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Setup the execution state
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
plpgsql_estate_setup(&estate, func, NULL);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Setup error traceback support for ereport()
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
plerrcontext.callback = plpgsql_exec_error_callback;
plerrcontext.arg = &estate;
plerrcontext.previous = error_context_stack;
error_context_stack = &plerrcontext;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Make local execution copies of all the datums
*/
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = gettext_noop("during initialization of execution state");
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
for (i = 0; i < estate.ndatums; i++)
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
estate.datums[i] = copy_plpgsql_datum(func->datums[i]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
* Put the OLD and NEW tuples into record variables
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
rec_new = (PLpgSQL_rec *) (estate.datums[func->new_varno]);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
rec_new->freetup = false;
rec_new->freetupdesc = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
rec_old = (PLpgSQL_rec *) (estate.datums[func->old_varno]);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
rec_old->freetup = false;
rec_old->freetupdesc = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (TRIGGER_FIRED_FOR_STATEMENT(trigdata->tg_event))
{
/*
* Per-statement triggers don't use OLD/NEW variables
*/
rec_new->tup = NULL;
rec_new->tupdesc = NULL;
rec_old->tup = NULL;
rec_old->tupdesc = NULL;
}
else if (TRIGGER_FIRED_BY_INSERT(trigdata->tg_event))
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
rec_new->tup = trigdata->tg_trigtuple;
rec_new->tupdesc = trigdata->tg_relation->rd_att;
rec_old->tup = NULL;
rec_old->tupdesc = NULL;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else if (TRIGGER_FIRED_BY_UPDATE(trigdata->tg_event))
{
rec_new->tup = trigdata->tg_newtuple;
rec_new->tupdesc = trigdata->tg_relation->rd_att;
rec_old->tup = trigdata->tg_trigtuple;
rec_old->tupdesc = trigdata->tg_relation->rd_att;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else if (TRIGGER_FIRED_BY_DELETE(trigdata->tg_event))
{
rec_new->tup = NULL;
rec_new->tupdesc = NULL;
rec_old->tup = trigdata->tg_trigtuple;
rec_old->tupdesc = trigdata->tg_relation->rd_att;
}
else
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized trigger action: not INSERT, DELETE, or UPDATE");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
* Assign the special tg_ variables
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
var = (PLpgSQL_var *) (estate.datums[func->tg_op_varno]);
if (TRIGGER_FIRED_BY_INSERT(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("INSERT");
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
else if (TRIGGER_FIRED_BY_UPDATE(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("UPDATE");
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
else if (TRIGGER_FIRED_BY_DELETE(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("DELETE");
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
else if (TRIGGER_FIRED_BY_TRUNCATE(trigdata->tg_event))
var->value = CStringGetTextDatum("TRUNCATE");
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
else
Support statement-level ON TRUNCATE triggers. Simon Riggs
2008-03-28 01:21:56 +01:00
elog(ERROR, "unrecognized trigger action: not INSERT, DELETE, UPDATE, or TRUNCATE");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
var->freeval = true;
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var = (PLpgSQL_var *) (estate.datums[func->tg_name_varno]);
More functions updated to new fmgr style --- money, name, tid datatypes. We're reaching the mopup stage here (good thing too, this is getting tedious).
2000-08-03 18:35:08 +02:00
var->value = DirectFunctionCall1(namein,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CStringGetDatum(trigdata->tg_trigger->tgname));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
var->freeval = true;
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var = (PLpgSQL_var *) (estate.datums[func->tg_when_varno]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (TRIGGER_FIRED_BEFORE(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("BEFORE");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else if (TRIGGER_FIRED_AFTER(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("AFTER");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized trigger execution time: not BEFORE or AFTER");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
var->freeval = true;
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var = (PLpgSQL_var *) (estate.datums[func->tg_level_varno]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (TRIGGER_FIRED_FOR_ROW(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("ROW");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else if (TRIGGER_FIRED_FOR_STATEMENT(trigdata->tg_event))
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
var->value = CStringGetTextDatum("STATEMENT");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized trigger event type: not ROW or STATEMENT");
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var->isnull = false;
var->freeval = true;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var = (PLpgSQL_var *) (estate.datums[func->tg_relid_varno]);
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var->value = ObjectIdGetDatum(trigdata->tg_relation->rd_id);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
var->freeval = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var = (PLpgSQL_var *) (estate.datums[func->tg_relname_varno]);
More functions updated to new fmgr style --- money, name, tid datatypes. We're reaching the mopup stage here (good thing too, this is getting tedious).
2000-08-03 18:35:08 +02:00
var->value = DirectFunctionCall1(namein,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
CStringGetDatum(RelationGetRelationName(trigdata->tg_relation)));
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var->isnull = false;
var->freeval = true;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
TG_table_name and TG_table_schema for plpgsql, plus docs and regression.
2006-05-28 05:03:17 +02:00
var = (PLpgSQL_var *) (estate.datums[func->tg_table_name_varno]);
var->value = DirectFunctionCall1(namein,
CStringGetDatum(RelationGetRelationName(trigdata->tg_relation)));
var->isnull = false;
var->freeval = true;
var = (PLpgSQL_var *) (estate.datums[func->tg_table_schema_varno]);
var->value = DirectFunctionCall1(namein,
CStringGetDatum(
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
get_namespace_name(
RelationGetNamespace(
trigdata->tg_relation))));
TG_table_name and TG_table_schema for plpgsql, plus docs and regression.
2006-05-28 05:03:17 +02:00
var->isnull = false;
var->freeval = true;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var = (PLpgSQL_var *) (estate.datums[func->tg_nargs_varno]);
Make initialization of special trigger variables a little more readable. Correct one mis-setting of freeval (which could at worst leak a few bytes until the trigger exits, so it's no big deal).
2005-03-25 02:45:42 +01:00
var->value = Int16GetDatum(trigdata->tg_trigger->tgnargs);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
var->freeval = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Store the trigger argument values into the special execution state
* variables
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = gettext_noop("while storing call arguments into local variables");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
estate.trig_nargs = trigdata->tg_trigger->tgnargs;
if (estate.trig_nargs == 0)
estate.trig_argv = NULL;
else
{
estate.trig_argv = palloc(sizeof(Datum) * estate.trig_nargs);
for (i = 0; i < trigdata->tg_trigger->tgnargs; i++)
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
estate.trig_argv[i] = CStringGetTextDatum(trigdata->tg_trigger->tgargs[i]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate.err_text = gettext_noop("during function entry");
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Set the magic variable FOUND to false
*/
exec_set_found(&estate, false);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/*
* Let the instrumentation plugin peek at this function
*/
if (*plugin_ptr && (*plugin_ptr)->func_beg)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->func_beg) (&estate, func);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Now call the toplevel block of statements
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate.err_text = NULL;
estate.err_stmt = (PLpgSQL_stmt *) (func->action);
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
rc = exec_stmt_block(&estate, func->action);
if (rc != PLPGSQL_RC_RETURN)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate.err_stmt = NULL;
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
estate.err_text = NULL;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
/*
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
* Provide a more helpful message if a CONTINUE or RAISE has been used
* outside the context it can work in.
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
*/
if (rc == PLPGSQL_RC_CONTINUE)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("CONTINUE cannot be used outside a loop")));
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
else if (rc == PLPGSQL_RC_RERAISE)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE without parameters cannot be used outside an exception handler")));
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
else
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_S_R_E_FUNCTION_EXECUTED_NO_RETURN_STATEMENT),
errmsg("control reached end of trigger procedure without RETURN")));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate.err_stmt = NULL;
estate.err_text = gettext_noop("during function exit");
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (estate.retisset)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("trigger procedure cannot return a set")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check that the returned tuple structure has the same attributes, the
* relation that fired the trigger has. A per-statement trigger always
* needs to return NULL, so we ignore any return value the function itself
* produces (XXX: is this a good idea?)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
* XXX This way it is possible, that the trigger returns a tuple where
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* attributes don't have the correct atttypmod's length. It's up to the
* trigger's programmer to ensure that this doesn't happen. Jan
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
This patch implements FOR EACH STATEMENT triggers, per my email to -hackers a couple days ago. Notes/caveats: - added regression tests for the new functionality, all regression tests pass on my machine - added pg_dump support - updated PL/PgSQL to support per-statement triggers; didn't look at the other procedural languages. - there's (even) more code duplication in trigger.c than there was previously. Any suggestions on how to refactor the ExecXXXTriggers() functions to reuse more code would be welcome -- I took a brief look at it, but couldn't see an easy way to do it (there are several subtly-different versions of the code in question) - updated the documentation. I also took the liberty of removing a big chunk of duplicated syntax documentation in the Programmer's Guide on triggers, and moving that information to the CREATE TRIGGER reference page. - I also included some spelling fixes and similar small cleanups I noticed while making the changes. If you'd like me to split those into a separate patch, let me know. Neil Conway
2002-11-23 04:59:09 +01:00
if (estate.retisnull || TRIGGER_FIRED_FOR_STATEMENT(trigdata->tg_event))
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
rettup = NULL;
else
{
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
validate_tupdesc_compat(trigdata->tg_relation->rd_att,
estate.rettupdesc,
gettext_noop("returned tuple structure does "
"not match table of trigger event"));
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* Copy tuple to upper executor memory */
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/*
* Let the instrumentation plugin peek at this function
*/
if (*plugin_ptr && (*plugin_ptr)->func_end)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->func_end) (&estate, func);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* Clean up any leftover temporary memory */
Minor code clarity improvement: AFAICS, estate.eval_econtext must be non-NULL during the guts of plpgsql_exec_trigger() and plpgsql_exec_function(). Therefore, we can remove the NULL check, per discussion on -patches.
2006-01-10 19:50:43 +01:00
FreeExprContext(estate.eval_econtext);
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
estate.eval_econtext = NULL;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(&estate);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Pop the error context stack
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
error_context_stack = plerrcontext.previous;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Allow the parameters to PL/PgSQL's RAISE statement to be expressions, instead of just scalar variables. Add regression tests and update the documentation. Along the way, remove some redundant error checking code from exec_stmt_perform(). Original patch from Pavel Stehule, reworked by Neil Conway.
2005-06-14 08:43:15 +02:00
* Return the trigger's result
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
return rettup;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
/*
* error context callback to let us supply a call-stack traceback
*/
static void
plpgsql_exec_error_callback(void *arg)
{
PLpgSQL_execstate *estate = (PLpgSQL_execstate *) arg;
/* safety check, shouldn't happen */
if (estate->err_func == NULL)
return;
/* if we are doing RAISE, don't report its location */
if (estate->err_text == raise_skip_msg)
return;
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
if (estate->err_text != NULL)
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We don't expend the cycles to run gettext() on err_text unless we
* actually need it. Therefore, places that set up err_text should
* use gettext_noop() to ensure the strings get recorded in the
* message dictionary.
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
*
* If both err_text and err_stmt are set, use the err_text as
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* description, but report the err_stmt's line number. When err_stmt
* is not set, we're in function entry/exit, or some such place not
* attached to a specific line number.
pgindent run.
2003-08-04 02:43:34 +02:00
*/
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
if (estate->err_stmt != NULL)
{
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* translator: last %s is a phrase such as "during statement block
* local variable initialization"
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
*/
errcontext("PL/pgSQL function \"%s\" line %d %s",
estate->err_func->fn_name,
estate->err_stmt->lineno,
gettext(estate->err_text));
}
else
{
/*
* translator: last %s is a phrase such as "while storing call
* arguments into local variables"
*/
errcontext("PL/pgSQL function \"%s\" %s",
estate->err_func->fn_name,
gettext(estate->err_text));
}
}
else if (estate->err_stmt != NULL)
{
/* translator: last %s is a plpgsql statement type name */
errcontext("PL/pgSQL function \"%s\" line %d at %s",
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_func->fn_name,
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_stmt->lineno,
plpgsql_stmt_typename(estate->err_stmt));
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
}
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
else
Fix some localizability issues with existing errcontext() calls.
2003-07-27 20:38:26 +02:00
errcontext("PL/pgSQL function \"%s\"",
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_func->fn_name);
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
* Support function for initializing local execution variables
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
static PLpgSQL_datum *
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
copy_plpgsql_datum(PLpgSQL_datum *datum)
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
{
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
PLpgSQL_datum *result;
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
switch (datum->dtype)
{
case PLPGSQL_DTYPE_VAR:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_var *new = palloc(sizeof(PLpgSQL_var));
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
memcpy(new, datum, sizeof(PLpgSQL_var));
/* Ensure the value is null (possibly not needed?) */
new->value = 0;
new->isnull = true;
new->freeval = false;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
result = (PLpgSQL_datum *) new;
}
break;
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
case PLPGSQL_DTYPE_REC:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_rec *new = palloc(sizeof(PLpgSQL_rec));
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
memcpy(new, datum, sizeof(PLpgSQL_rec));
/* Ensure the value is null (possibly not needed?) */
new->tup = NULL;
new->tupdesc = NULL;
new->freetup = false;
new->freetupdesc = false;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
result = (PLpgSQL_datum *) new;
}
break;
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
case PLPGSQL_DTYPE_ROW:
case PLPGSQL_DTYPE_RECFIELD:
case PLPGSQL_DTYPE_ARRAYELEM:
case PLPGSQL_DTYPE_TRIGARG:
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* These datum records are read-only at runtime, so no need to
* copy them
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
*/
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
result = datum;
break;
default:
elog(ERROR, "unrecognized dtype: %d", datum->dtype);
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
result = NULL; /* keep compiler quiet */
break;
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
}
return result;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
static bool
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exception_matches_conditions(ErrorData *edata, PLpgSQL_condition *cond)
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
{
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
for (; cond != NULL; cond = cond->next)
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
{
Recognize plpgsql EXCEPTION condition names at function compile time instead of runtime, for better detection of invalid condition names (and maybe a little more speed, too).
2004-08-21 00:00:14 +02:00
int sqlerrstate = cond->sqlerrstate;
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
/*
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* OTHERS matches everything *except* query-canceled; if you're
* foolish enough, you can match that explicitly.
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
*/
Recognize plpgsql EXCEPTION condition names at function compile time instead of runtime, for better detection of invalid condition names (and maybe a little more speed, too).
2004-08-21 00:00:14 +02:00
if (sqlerrstate == 0)
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
{
Recognize plpgsql EXCEPTION condition names at function compile time instead of runtime, for better detection of invalid condition names (and maybe a little more speed, too).
2004-08-21 00:00:14 +02:00
if (edata->sqlerrcode != ERRCODE_QUERY_CANCELED)
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
return true;
}
Recognize plpgsql EXCEPTION condition names at function compile time instead of runtime, for better detection of invalid condition names (and maybe a little more speed, too).
2004-08-21 00:00:14 +02:00
/* Exact match? */
else if (edata->sqlerrcode == sqlerrstate)
return true;
/* Category match? */
else if (ERRCODE_IS_CATEGORY(sqlerrstate) &&
ERRCODE_TO_CATEGORY(edata->sqlerrcode) == sqlerrstate)
return true;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
}
return false;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_stmt_block Execute a block of statements
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_block(PLpgSQL_execstate *estate, PLpgSQL_stmt_block *block)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
volatile int rc = -1;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int i;
int n;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* First initialize all variables declared in this block
*/
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = gettext_noop("during statement block local variable initialization");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
for (i = 0; i < block->n_initvars; i++)
{
n = block->initvarnos[i];
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (estate->datums[n]->dtype)
{
case PLPGSQL_DTYPE_VAR:
{
PLpgSQL_var *var = (PLpgSQL_var *) (estate->datums[n]);
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
/* free any old value, in case re-entering block */
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
free_var(var);
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
/* Initially it contains a NULL */
var->value = (Datum) 0;
var->isnull = true;
if (var->default_val == NULL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
/*
* If needed, give the datatype a chance to reject
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* NULLs, by assigning a NULL to the variable. We
* claim the value is of type UNKNOWN, not the var's
* datatype, else coercion will be skipped. (Do this
* before the notnull check to be consistent with
* exec_assign_value.)
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
*/
if (!var->datatype->typinput.fn_strict)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
bool valIsNull = true;
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
exec_assign_value(estate,
(PLpgSQL_datum *) var,
(Datum) 0,
UNKNOWNOID,
&valIsNull);
}
if (var->notnull)
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("variable \"%s\" declared NOT NULL cannot default to NULL",
var->refname)));
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
}
else
{
exec_assign_expr(estate, (PLpgSQL_datum *) var,
var->default_val);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
}
break;
case PLPGSQL_DTYPE_REC:
{
PLpgSQL_rec *rec = (PLpgSQL_rec *) (estate->datums[n]);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (rec->freetup)
{
heap_freetuple(rec->tup);
FreeTupleDesc(rec->tupdesc);
rec->freetup = false;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
rec->tup = NULL;
rec->tupdesc = NULL;
}
break;
case PLPGSQL_DTYPE_RECFIELD:
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
case PLPGSQL_DTYPE_ARRAYELEM:
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized dtype: %d",
estate->datums[n]->dtype);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
}
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
if (block->exceptions)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Execute the statements in the block's body inside a sub-transaction
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
*/
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
MemoryContext oldcontext = CurrentMemoryContext;
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
ResourceOwner oldowner = CurrentResourceOwner;
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
ExprContext *old_eval_econtext = estate->eval_econtext;
EState *old_eval_estate = estate->eval_estate;
long int old_eval_estate_simple_id = estate->eval_estate_simple_id;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = gettext_noop("during statement block entry");
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
BeginInternalSubTransaction(NULL);
/* Want to run statements inside function's memory context */
MemoryContextSwitchTo(oldcontext);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
PG_TRY();
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
{
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
/*
* We need to run the block's statements with a new eval_econtext
* that belongs to the current subtransaction; if we try to use
* the outer econtext then ExprContext shutdown callbacks will be
* called at the wrong times.
*/
plpgsql_create_econtext(estate);
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = NULL;
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
/* Run the block's statements */
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
rc = exec_stmts(estate, block->body);
While fixing plperl and pltcl, I realized plpgsql wasn't doing subtransactions quite right either: the ReleaseCurrentSubTransaction call should occur inside the PG_TRY, so that the proper path is taken if an error occurs during subtransaction commit. This assumes that AbortSubTransaction can cope with the state left behind if CommitSubTransaction fails partway through, but we were already requiring that.
2004-11-21 23:27:34 +01:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = gettext_noop("during statement block exit");
Fix plpgsql to avoid reference to already-freed memory when returning a pass-by-reference data type and the RETURN statement is within an EXCEPTION block. Bug introduced by my fix of 2007-01-28 to use per-subtransaction ExprContexts/EStates; since that wasn't back-patched into older branches, only 8.2 and HEAD are affected. Per report from Gary Winslow.
2007-04-19 18:33:24 +02:00
/*
* If the block ended with RETURN, we may need to copy the return
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* value out of the subtransaction eval_context. This is
* currently only needed for scalar result types --- rowtype
* values will always exist in the function's own memory context.
Fix plpgsql to avoid reference to already-freed memory when returning a pass-by-reference data type and the RETURN statement is within an EXCEPTION block. Bug introduced by my fix of 2007-01-28 to use per-subtransaction ExprContexts/EStates; since that wasn't back-patched into older branches, only 8.2 and HEAD are affected. Per report from Gary Winslow.
2007-04-19 18:33:24 +02:00
*/
if (rc == PLPGSQL_RC_RETURN &&
!estate->retisset &&
!estate->retisnull &&
estate->rettupdesc == NULL)
{
int16 resTypLen;
bool resTypByVal;
get_typlenbyval(estate->rettype, &resTypLen, &resTypByVal);
estate->retval = datumCopy(estate->retval,
resTypByVal, resTypLen);
}
While fixing plperl and pltcl, I realized plpgsql wasn't doing subtransactions quite right either: the ReleaseCurrentSubTransaction call should occur inside the PG_TRY, so that the proper path is taken if an error occurs during subtransaction commit. This assumes that AbortSubTransaction can cope with the state left behind if CommitSubTransaction fails partway through, but we were already requiring that.
2004-11-21 23:27:34 +01:00
/* Commit the inner transaction, return to outer xact context */
ReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
CurrentResourceOwner = oldowner;
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
/* Revert to outer eval_econtext */
estate->eval_econtext = old_eval_econtext;
estate->eval_estate = old_eval_estate;
estate->eval_estate_simple_id = old_eval_estate_simple_id;
While fixing plperl and pltcl, I realized plpgsql wasn't doing subtransactions quite right either: the ReleaseCurrentSubTransaction call should occur inside the PG_TRY, so that the proper path is taken if an error occurs during subtransaction commit. This assumes that AbortSubTransaction can cope with the state left behind if CommitSubTransaction fails partway through, but we were already requiring that.
2004-11-21 23:27:34 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* AtEOSubXact_SPI() should not have popped any SPI context, but
* just in case it did, make sure we remain connected.
While fixing plperl and pltcl, I realized plpgsql wasn't doing subtransactions quite right either: the ReleaseCurrentSubTransaction call should occur inside the PG_TRY, so that the proper path is taken if an error occurs during subtransaction commit. This assumes that AbortSubTransaction can cope with the state left behind if CommitSubTransaction fails partway through, but we were already requiring that.
2004-11-21 23:27:34 +01:00
*/
SPI_restore_connection();
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
}
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
PG_CATCH();
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
ErrorData *edata;
ListCell *e;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = gettext_noop("during exception cleanup");
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
/* Save error info */
MemoryContextSwitchTo(oldcontext);
edata = CopyErrorData();
FlushErrorState();
Rethink plpgsql's way of handling SPI execution during an exception block. We don't really want to start a new SPI connection, just keep using the old one; otherwise we have memory management problems as illustrated by John Kennedy's bug report of today. This requires a bit of a hack to ensure the SPI stack state is properly restored, but then again what we were doing before was a hack too, strictly speaking. Add a regression test to cover this case.
2004-11-16 19:10:16 +01:00
/* Abort the inner transaction */
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
RollbackAndReleaseCurrentSubTransaction();
MemoryContextSwitchTo(oldcontext);
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
CurrentResourceOwner = oldowner;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
/* Revert to outer eval_econtext */
estate->eval_econtext = old_eval_econtext;
estate->eval_estate = old_eval_estate;
estate->eval_estate_simple_id = old_eval_estate_simple_id;
Rethink plpgsql's way of handling SPI execution during an exception block. We don't really want to start a new SPI connection, just keep using the old one; otherwise we have memory management problems as illustrated by John Kennedy's bug report of today. This requires a bit of a hack to ensure the SPI stack state is properly restored, but then again what we were doing before was a hack too, strictly speaking. Add a regression test to cover this case.
2004-11-16 19:10:16 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If AtEOSubXact_SPI() popped any SPI context of the subxact, it
* will have left us in a disconnected state. We need this hack
* to return to connected state.
Rethink plpgsql's way of handling SPI execution during an exception block. We don't really want to start a new SPI connection, just keep using the old one; otherwise we have memory management problems as illustrated by John Kennedy's bug report of today. This requires a bit of a hack to ensure the SPI stack state is properly restored, but then again what we were doing before was a hack too, strictly speaking. Add a regression test to cover this case.
2004-11-16 19:10:16 +01:00
*/
SPI_restore_connection();
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
/* Look for a matching exception handler */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
foreach(e, block->exceptions->exc_list)
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
{
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
PLpgSQL_exception *exception = (PLpgSQL_exception *) lfirst(e);
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
Support "OR condition ..." in plpgsql EXCEPTION clauses to make the syntax more nearly Oracle-equivalent. Allow matching by category as well as specific error code. Document the set of available condition names (or more accurately, synchronize it with the existing documentation). In passing, update errcodes.sgml to include codes added during 7.5 development.
2004-08-01 01:04:58 +02:00
if (exception_matches_conditions(edata, exception->conditions))
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
{
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Initialize the magic SQLSTATE and SQLERRM variables for
* the exception block. We needn't do this until we have
* found a matching exception.
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
*/
PLpgSQL_var *state_var;
PLpgSQL_var *errm_var;
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
state_var = (PLpgSQL_var *)
estate->datums[block->exceptions->sqlstate_varno];
errm_var = (PLpgSQL_var *)
estate->datums[block->exceptions->sqlerrm_varno];
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
assign_text_var(state_var,
unpack_sql_state(edata->sqlerrcode));
assign_text_var(errm_var, edata->message);
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = NULL;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
rc = exec_stmts(estate, exception->action);
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
free_var(state_var);
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
state_var->value = (Datum) 0;
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
state_var->isnull = true;
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
free_var(errm_var);
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
errm_var->value = (Datum) 0;
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
errm_var->isnull = true;
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
/* re-throw error if requested by handler */
if (rc == PLPGSQL_RC_RERAISE)
ReThrowError(edata);
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
break;
}
}
/* If no match found, re-throw the error */
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
if (e == NULL)
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
ReThrowError(edata);
else
FreeErrorData(edata);
}
PG_END_TRY();
}
else
{
/*
* Just execute the statements in the block's body
*/
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = NULL;
plpgsql does exceptions. There are still some things that need refinement; in particular I fear that the recognized set of error condition names probably has little in common with what Oracle recognizes. But it's a start.
2004-07-31 09:39:21 +02:00
rc = exec_stmts(estate, block->body);
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Make some small improvements in the accuracy of plpgsql's error location reports; inspired by the misleading CONTEXT lines shown in recent bug report from Stefan Kaltenbrunner. Also, allow statement-type names shown in these messages to be translated.
2007-01-28 18:58:13 +01:00
estate->err_text = NULL;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Handle the return code.
*/
switch (rc)
{
case PLPGSQL_RC_OK:
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
case PLPGSQL_RC_RETURN:
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
case PLPGSQL_RC_CONTINUE:
case PLPGSQL_RC_RERAISE:
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
return rc;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_RC_EXIT:
if (estate->exitlabel == NULL)
return PLPGSQL_RC_OK;
if (block->label == NULL)
return PLPGSQL_RC_EXIT;
if (strcmp(block->label, estate->exitlabel))
return PLPGSQL_RC_EXIT;
estate->exitlabel = NULL;
return PLPGSQL_RC_OK;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized rc: %d", rc);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmts Iterate over a list of statements
* as long as their return code is OK
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmts(PLpgSQL_execstate *estate, List *stmts)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
ListCell *s;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Ensure that a plpgsql LOOP with an empty body still executes at least one CHECK_FOR_INTERRUPTS() call, so that you can control-C out of the loop. Reported by Merlin Moncure.
2005-10-24 17:10:22 +02:00
if (stmts == NIL)
{
/*
* Ensure we do a CHECK_FOR_INTERRUPTS() even though there is no
* statement. This prevents hangup in a tight loop if, for instance,
* there is a LOOP construct with an empty body.
*/
CHECK_FOR_INTERRUPTS();
return PLPGSQL_RC_OK;
}
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
foreach(s, stmts)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
PLpgSQL_stmt *stmt = (PLpgSQL_stmt *) lfirst(s);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int rc = exec_stmt(estate, stmt);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (rc != PLPGSQL_RC_OK)
return rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt Distribute one statement to the statements
* type specific execution function.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt(PLpgSQL_execstate *estate, PLpgSQL_stmt *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_stmt *save_estmt;
int rc = -1;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
save_estmt = estate->err_stmt;
estate->err_stmt = stmt;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/* Let the plugin know that we are about to execute this statement */
if (*plugin_ptr && (*plugin_ptr)->stmt_beg)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->stmt_beg) (estate, stmt);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
CHECK_FOR_INTERRUPTS();
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
switch ((enum PLpgSQL_stmt_types) stmt->cmd_type)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
case PLPGSQL_STMT_BLOCK:
rc = exec_stmt_block(estate, (PLpgSQL_stmt_block *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_ASSIGN:
rc = exec_stmt_assign(estate, (PLpgSQL_stmt_assign *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
case PLPGSQL_STMT_PERFORM:
rc = exec_stmt_perform(estate, (PLpgSQL_stmt_perform *) stmt);
break;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
case PLPGSQL_STMT_GETDIAG:
rc = exec_stmt_getdiag(estate, (PLpgSQL_stmt_getdiag *) stmt);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_IF:
rc = exec_stmt_if(estate, (PLpgSQL_stmt_if *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
case PLPGSQL_STMT_CASE:
rc = exec_stmt_case(estate, (PLpgSQL_stmt_case *) stmt);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_LOOP:
rc = exec_stmt_loop(estate, (PLpgSQL_stmt_loop *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_WHILE:
rc = exec_stmt_while(estate, (PLpgSQL_stmt_while *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_FORI:
rc = exec_stmt_fori(estate, (PLpgSQL_stmt_fori *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_FORS:
rc = exec_stmt_fors(estate, (PLpgSQL_stmt_fors *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
case PLPGSQL_STMT_FORC:
rc = exec_stmt_forc(estate, (PLpgSQL_stmt_forc *) stmt);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_EXIT:
rc = exec_stmt_exit(estate, (PLpgSQL_stmt_exit *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_RETURN:
rc = exec_stmt_return(estate, (PLpgSQL_stmt_return *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
case PLPGSQL_STMT_RETURN_NEXT:
rc = exec_stmt_return_next(estate, (PLpgSQL_stmt_return_next *) stmt);
break;
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
case PLPGSQL_STMT_RETURN_QUERY:
rc = exec_stmt_return_query(estate, (PLpgSQL_stmt_return_query *) stmt);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_RAISE:
rc = exec_stmt_raise(estate, (PLpgSQL_stmt_raise *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_STMT_EXECSQL:
rc = exec_stmt_execsql(estate, (PLpgSQL_stmt_execsql *) stmt);
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
case PLPGSQL_STMT_DYNEXECUTE:
rc = exec_stmt_dynexecute(estate, (PLpgSQL_stmt_dynexecute *) stmt);
break;
case PLPGSQL_STMT_DYNFORS:
rc = exec_stmt_dynfors(estate, (PLpgSQL_stmt_dynfors *) stmt);
break;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
case PLPGSQL_STMT_OPEN:
rc = exec_stmt_open(estate, (PLpgSQL_stmt_open *) stmt);
break;
case PLPGSQL_STMT_FETCH:
rc = exec_stmt_fetch(estate, (PLpgSQL_stmt_fetch *) stmt);
break;
case PLPGSQL_STMT_CLOSE:
rc = exec_stmt_close(estate, (PLpgSQL_stmt_close *) stmt);
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_stmt = save_estmt;
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized cmdtype: %d", stmt->cmd_type);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/* Let the plugin know that we have finished executing this statement */
if (*plugin_ptr && (*plugin_ptr)->stmt_end)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->stmt_end) (estate, stmt);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_stmt = save_estmt;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt_assign Evaluate an expression and
* put the result into a variable.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_assign(PLpgSQL_execstate *estate, PLpgSQL_stmt_assign *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
Assert(stmt->varno >= 0);
Cause plpgsql's PERFORM to behave according to its documentation, which says that PERFORM will execute any SELECT query and discard the result. The former implementation would in fact raise an error if the result contained more than one row or more than one column. Also, change plpgsql's error-logging mechanism to emit the additional messages about error location at NOTICE rather than DEBUG level. This allows them to be seen by the client without having to dig into the postmaster log file (which may be nonexistent or inaccessible by the client).
2001-05-28 21:33:24 +02:00
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
exec_assign_expr(estate, estate->datums[stmt->varno], stmt->expr);
Cause plpgsql's PERFORM to behave according to its documentation, which says that PERFORM will execute any SELECT query and discard the result. The former implementation would in fact raise an error if the result contained more than one row or more than one column. Also, change plpgsql's error-logging mechanism to emit the additional messages about error location at NOTICE rather than DEBUG level. This allows them to be seen by the client without having to dig into the postmaster log file (which may be nonexistent or inaccessible by the client).
2001-05-28 21:33:24 +02:00
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
return PLPGSQL_RC_OK;
}
/* ----------
* exec_stmt_perform Evaluate query and discard result (but set
* FOUND depending on whether at least one row
* was returned).
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_perform(PLpgSQL_execstate *estate, PLpgSQL_stmt_perform *stmt)
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
{
PLpgSQL_expr *expr = stmt->expr;
Cause plpgsql's PERFORM to behave according to its documentation, which says that PERFORM will execute any SELECT query and discard the result. The former implementation would in fact raise an error if the result contained more than one row or more than one column. Also, change plpgsql's error-logging mechanism to emit the additional messages about error location at NOTICE rather than DEBUG level. This allows them to be seen by the client without having to dig into the postmaster log file (which may be nonexistent or inaccessible by the client).
2001-05-28 21:33:24 +02:00
Allow the parameters to PL/PgSQL's RAISE statement to be expressions, instead of just scalar variables. Add regression tests and update the documentation. Along the way, remove some redundant error checking code from exec_stmt_perform(). Original patch from Pavel Stehule, reworked by Neil Conway.
2005-06-14 08:43:15 +02:00
(void) exec_run_select(estate, expr, 0, NULL);
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
exec_set_found(estate, (estate->eval_processed != 0));
exec_eval_cleanup(estate);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
/* ----------
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
* exec_stmt_getdiag Put internal PG information into
* specified variables.
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_getdiag(PLpgSQL_execstate *estate, PLpgSQL_stmt_getdiag *stmt)
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
ListCell *lc;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
foreach(lc, stmt->diag_items)
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
PLpgSQL_diag_item *diag_item = (PLpgSQL_diag_item *) lfirst(lc);
PLpgSQL_datum *var;
bool isnull = false;
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
if (diag_item->target <= 0)
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
continue;
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
var = estate->datums[diag_item->target];
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
if (var == NULL)
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
continue;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
switch (diag_item->kind)
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
{
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
case PLPGSQL_GETDIAG_ROW_COUNT:
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_assign_value(estate, var,
UInt32GetDatum(estate->eval_processed),
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
INT4OID, &isnull);
break;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
case PLPGSQL_GETDIAG_RESULT_OID:
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_assign_value(estate, var,
ObjectIdGetDatum(estate->eval_lastoid),
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
OIDOID, &isnull);
break;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized attribute request: %d",
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
diag_item->kind);
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
}
}
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
Change plpgsql's GET DIAGNOSTICS statement to use SQL99-compatible syntax. Fix the RESULT_OID case, which never worked. Add documentation.
2001-02-19 20:49:53 +01:00
return PLPGSQL_RC_OK;
GET DIAGNOSTICS statement to PL/pgSQL to access SPI_processed and SPI_return values. Patch from Philip Warner. Jan
2000-09-05 11:02:18 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_stmt_if Evaluate a bool expression and
* execute the true or false body
* conditionally.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_if(PLpgSQL_execstate *estate, PLpgSQL_stmt_if *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
bool value;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
bool isnull;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
value = exec_eval_boolean(estate, stmt->cond, &isnull);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
if (!isnull && value)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
if (stmt->true_body != NIL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return exec_stmts(estate, stmt->true_body);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
{
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
if (stmt->false_body != NIL)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return exec_stmts(estate, stmt->false_body);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
/*-----------
* exec_stmt_case
*-----------
*/
static int
exec_stmt_case(PLpgSQL_execstate *estate, PLpgSQL_stmt_case *stmt)
{
PLpgSQL_var *t_var = NULL;
bool isnull;
ListCell *l;
if (stmt->t_expr != NULL)
{
/* simple case */
Datum t_val;
Oid t_oid;
t_val = exec_eval_expr(estate, stmt->t_expr, &isnull, &t_oid);
t_var = (PLpgSQL_var *) estate->datums[stmt->t_varno];
/*
* When expected datatype is different from real, change it.
* Note that what we're modifying here is an execution copy
* of the datum, so this doesn't affect the originally stored
* function parse tree.
*/
if (t_var->datatype->typoid != t_oid)
t_var->datatype = plpgsql_build_datatype(t_oid, -1);
/* now we can assign to the variable */
exec_assign_value(estate,
(PLpgSQL_datum *) t_var,
t_val,
t_oid,
&isnull);
exec_eval_cleanup(estate);
}
/* Now search for a successful WHEN clause */
foreach(l, stmt->case_when_list)
{
PLpgSQL_case_when *cwt = (PLpgSQL_case_when *) lfirst(l);
bool value;
value = exec_eval_boolean(estate, cwt->expr, &isnull);
exec_eval_cleanup(estate);
if (!isnull && value)
{
/* Found it */
/* We can now discard any value we had for the temp variable */
if (t_var != NULL)
{
free_var(t_var);
t_var->value = (Datum) 0;
t_var->isnull = true;
}
/* Evaluate the statement(s), and we're done */
return exec_stmts(estate, cwt->stmts);
}
}
/* We can now discard any value we had for the temp variable */
if (t_var != NULL)
{
free_var(t_var);
t_var->value = (Datum) 0;
t_var->isnull = true;
}
/* SQL2003 mandates this error if there was no ELSE clause */
if (!stmt->have_else)
ereport(ERROR,
(errcode(ERRCODE_CASE_NOT_FOUND),
errmsg("case not found"),
errhint("CASE statement is missing ELSE part.")));
/* Evaluate the ELSE statements, and we're done */
return exec_stmts(estate, stmt->else_stmts);
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_stmt_loop Loop over statements until
* an exit occurs.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_loop(PLpgSQL_execstate *estate, PLpgSQL_stmt_loop *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
for (;;)
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
int rc = exec_stmts(estate, stmt->body);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (rc)
{
case PLPGSQL_RC_OK:
break;
case PLPGSQL_RC_EXIT:
if (estate->exitlabel == NULL)
return PLPGSQL_RC_OK;
if (stmt->label == NULL)
return PLPGSQL_RC_EXIT;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
if (strcmp(stmt->label, estate->exitlabel) != 0)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_EXIT;
estate->exitlabel = NULL;
return PLPGSQL_RC_OK;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
case PLPGSQL_RC_CONTINUE:
if (estate->exitlabel == NULL)
/* anonymous continue, so re-run the loop */
break;
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
/* label matches named continue, so re-run loop */
estate->exitlabel = NULL;
else
/* label doesn't match named continue, so propagate upward */
return PLPGSQL_RC_CONTINUE;
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_RC_RETURN:
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
case PLPGSQL_RC_RERAISE:
return rc;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized rc: %d", rc);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt_while Loop over statements as long
* as an expression evaluates to
* true or an exit occurs.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_while(PLpgSQL_execstate *estate, PLpgSQL_stmt_while *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
for (;;)
{
Fix bug in CONTINUE statement for PL/pgSQL: when we continue a loop, we need to be careful to reset rc to PLPGSQL_RC_OK, depending on how the loop's logic is structured. If we continue a loop but it then exits without executing the loop's body again, we want to return PLPGSQL_RC_OK to our caller. Enhance the regression tests to catch this problem. Per report from Michael Fuhr.
2005-06-22 09:28:47 +02:00
int rc;
bool value;
bool isnull;
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
value = exec_eval_boolean(estate, stmt->cond, &isnull);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
if (isnull || !value)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
rc = exec_stmts(estate, stmt->body);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (rc)
{
case PLPGSQL_RC_OK:
break;
case PLPGSQL_RC_EXIT:
if (estate->exitlabel == NULL)
return PLPGSQL_RC_OK;
if (stmt->label == NULL)
return PLPGSQL_RC_EXIT;
if (strcmp(stmt->label, estate->exitlabel))
return PLPGSQL_RC_EXIT;
estate->exitlabel = NULL;
return PLPGSQL_RC_OK;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
case PLPGSQL_RC_CONTINUE:
if (estate->exitlabel == NULL)
/* anonymous continue, so re-run loop */
break;
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
/* label matches named continue, so re-run loop */
estate->exitlabel = NULL;
else
/* label doesn't match named continue, propagate upward */
return PLPGSQL_RC_CONTINUE;
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
case PLPGSQL_RC_RETURN:
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
case PLPGSQL_RC_RERAISE:
return rc;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized rc: %d", rc);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt_fori Iterate an integer variable
Add BY clause to PL/PgSQL FOR loop, to control the iteration increment. Jaime Casanova
2006-06-12 18:45:30 +02:00
* from a lower to an upper value
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
* incrementing or decrementing by the BY value
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_fori(PLpgSQL_execstate *estate, PLpgSQL_stmt_fori *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_var *var;
Datum value;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
bool isnull;
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
Oid valtype;
int32 loop_value;
int32 end_value;
int32 step_value;
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
bool found = false;
int rc = PLPGSQL_RC_OK;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
var = (PLpgSQL_var *) (estate->datums[stmt->var->varno]);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
* Get the value of the lower bound
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
value = exec_eval_expr(estate, stmt->lower, &isnull, &valtype);
value = exec_cast_value(value, valtype, var->datatype->typoid,
&(var->datatype->typinput),
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
var->datatype->typioparam,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
var->datatype->atttypmod, isnull);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("lower bound of FOR loop cannot be NULL")));
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
loop_value = DatumGetInt32(value);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Get the value of the upper bound
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
value = exec_eval_expr(estate, stmt->upper, &isnull, &valtype);
value = exec_cast_value(value, valtype, var->datatype->typoid,
&(var->datatype->typinput),
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
var->datatype->typioparam,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
var->datatype->atttypmod, isnull);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("upper bound of FOR loop cannot be NULL")));
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
end_value = DatumGetInt32(value);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add BY clause to PL/PgSQL FOR loop, to control the iteration increment. Jaime Casanova
2006-06-12 18:45:30 +02:00
/*
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
* Get the step value
Add BY clause to PL/PgSQL FOR loop, to control the iteration increment. Jaime Casanova
2006-06-12 18:45:30 +02:00
*/
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
if (stmt->step)
{
value = exec_eval_expr(estate, stmt->step, &isnull, &valtype);
value = exec_cast_value(value, valtype, var->datatype->typoid,
&(var->datatype->typinput),
var->datatype->typioparam,
var->datatype->atttypmod, isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("BY value of FOR loop cannot be NULL")));
step_value = DatumGetInt32(value);
exec_eval_cleanup(estate);
if (step_value <= 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
errmsg("BY value of FOR loop must be greater than zero")));
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
}
else
step_value = 1;
Add BY clause to PL/PgSQL FOR loop, to control the iteration increment. Jaime Casanova
2006-06-12 18:45:30 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Now do the loop
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
for (;;)
{
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
* Check against upper bound
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (stmt->reverse)
{
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
if (loop_value < end_value)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
{
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
if (loop_value > end_value)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
pgindent run.
2002-09-04 22:31:48 +02:00
found = true; /* looped at least once */
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
/*
* Assign current value to loop var
*/
var->value = Int32GetDatum(loop_value);
var->isnull = false;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Execute the statements
*/
rc = exec_stmts(estate, stmt->body);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
if (rc == PLPGSQL_RC_RETURN ||
rc == PLPGSQL_RC_RERAISE)
break; /* break out of the loop */
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
else if (rc == PLPGSQL_RC_EXIT)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
if (estate->exitlabel == NULL)
/* unlabelled exit, finish the current loop */
rc = PLPGSQL_RC_OK;
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
{
/* labelled exit, matches the current stmt's label */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
estate->exitlabel = NULL;
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
rc = PLPGSQL_RC_OK;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* otherwise, this is a labelled exit that does not match the
* current statement's label, if any: return RC_EXIT so that the
* EXIT continues to propagate up the stack.
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
*/
break;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
else if (rc == PLPGSQL_RC_CONTINUE)
{
if (estate->exitlabel == NULL)
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
/* unlabelled continue, so re-run the current loop */
Fix bug in CONTINUE statement for PL/pgSQL: when we continue a loop, we need to be careful to reset rc to PLPGSQL_RC_OK, depending on how the loop's logic is structured. If we continue a loop but it then exits without executing the loop's body again, we want to return PLPGSQL_RC_OK to our caller. Enhance the regression tests to catch this problem. Per report from Michael Fuhr.
2005-06-22 09:28:47 +02:00
rc = PLPGSQL_RC_OK;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
{
Fix bug in CONTINUE statement for PL/pgSQL: when we continue a loop, we need to be careful to reset rc to PLPGSQL_RC_OK, depending on how the loop's logic is structured. If we continue a loop but it then exits without executing the loop's body again, we want to return PLPGSQL_RC_OK to our caller. Enhance the regression tests to catch this problem. Per report from Michael Fuhr.
2005-06-22 09:28:47 +02:00
/* label matches named continue, so re-run loop */
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
estate->exitlabel = NULL;
Fix bug in CONTINUE statement for PL/pgSQL: when we continue a loop, we need to be careful to reset rc to PLPGSQL_RC_OK, depending on how the loop's logic is structured. If we continue a loop but it then exits without executing the loop's body again, we want to return PLPGSQL_RC_OK to our caller. Enhance the regression tests to catch this problem. Per report from Michael Fuhr.
2005-06-22 09:28:47 +02:00
rc = PLPGSQL_RC_OK;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
}
else
{
Fix breakage introduced in plpgsql CONTINUE patch. Per Kevin McArthur.
2005-07-28 02:26:30 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* otherwise, this is a named continue that does not match the
* current statement's label, if any: return RC_CONTINUE so
* that the CONTINUE will propagate up the stack.
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
*/
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
break;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
}
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
* Increase/decrease loop value, unless it would overflow, in which
* case exit the loop.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (stmt->reverse)
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
{
if ((int32) (loop_value - step_value) > loop_value)
break;
loop_value -= step_value;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
Reject zero or negative BY step in plpgsql integer FOR-loops, and behave sanely if the loop value overflows int32 on the way to the end value. Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some type-punning between Datum and int4 that dates from the original coding.
2007-07-15 04:15:04 +02:00
{
if ((int32) (loop_value + step_value) < loop_value)
break;
loop_value += step_value;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
/*
pgindent run.
2002-09-04 22:31:48 +02:00
* Set the FOUND variable to indicate the result of executing the loop
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* (namely, whether we looped one or more times). This must be set here so
* that it does not interfere with the value of the FOUND variable inside
* the loop processing itself.
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
*/
exec_set_found(estate, found);
return rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt_fors Execute a query, assign each
* tuple to a record or row and
* execute a group of statements
* for it.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_fors(PLpgSQL_execstate *estate, PLpgSQL_stmt_fors *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Portal portal;
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
int rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Open the implicit cursor for the statement using exec_run_select
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
exec_run_select(estate, stmt->query, 0, &portal);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Execute the loop
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
rc = exec_for_query(estate, (PLpgSQL_stmt_forq *) stmt, portal, true);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Close the implicit cursor
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
SPI_cursor_close(portal);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
return rc;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/* ----------
* exec_stmt_forc Execute a loop for each row from a cursor.
* ----------
*/
static int
exec_stmt_forc(PLpgSQL_execstate *estate, PLpgSQL_stmt_forc *stmt)
{
PLpgSQL_var *curvar;
char *curname = NULL;
PLpgSQL_expr *query;
Portal portal;
int rc;
Datum *values;
char *nulls;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/* ----------
* Get the cursor variable and if it has an assigned name, check
* that it's not in use currently.
* ----------
*/
curvar = (PLpgSQL_var *) (estate->datums[stmt->curvar]);
if (!curvar->isnull)
{
curname = TextDatumGetCString(curvar->value);
if (SPI_cursor_find(curname) != NULL)
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_CURSOR),
errmsg("cursor \"%s\" already in use", curname)));
}
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/* ----------
* Open the cursor just like an OPEN command
*
* Note: parser should already have checked that statement supplies
* args iff cursor needs them, but we check again to be safe.
* ----------
*/
if (stmt->argquery != NULL)
{
/* ----------
* OPEN CURSOR with args. We fake a SELECT ... INTO ...
* statement to evaluate the args and put 'em into the
* internal row.
* ----------
*/
PLpgSQL_stmt_execsql set_args;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
if (curvar->cursor_explicit_argrow < 0)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("arguments given for cursor without arguments")));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
memset(&set_args, 0, sizeof(set_args));
set_args.cmd_type = PLPGSQL_STMT_EXECSQL;
set_args.lineno = stmt->lineno;
set_args.sqlstmt = stmt->argquery;
set_args.into = true;
/* XXX historically this has not been STRICT */
set_args.row = (PLpgSQL_row *)
(estate->datums[curvar->cursor_explicit_argrow]);
if (exec_stmt_execsql(estate, &set_args) != PLPGSQL_RC_OK)
elog(ERROR, "open cursor failed during argument processing");
}
else
{
if (curvar->cursor_explicit_argrow >= 0)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("arguments required for cursor")));
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
query = curvar->cursor_explicit_expr;
Assert(query);
if (query->plan == NULL)
exec_prepare_plan(estate, query, curvar->cursor_options);
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Now build up the values and nulls arguments for SPI_execute_plan()
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
eval_expr_params(estate, query, &values, &nulls);
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Open the cursor
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
portal = SPI_cursor_open(curname, query->plan, values, nulls,
estate->readonly_func);
if (portal == NULL)
elog(ERROR, "could not open cursor: %s",
SPI_result_code_string(SPI_result));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* If cursor variable was NULL, store the generated portal name in it
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
if (curname == NULL)
assign_text_var(curvar, portal->name);
/*
* Execute the loop. We can't prefetch because the cursor is accessible
* to the user, for instance via UPDATE WHERE CURRENT OF within the loop.
*/
rc = exec_for_query(estate, (PLpgSQL_stmt_forq *) stmt, portal, false);
/* ----------
* Close portal, and restore cursor variable if it was initially NULL.
* ----------
*/
SPI_cursor_close(portal);
if (curname == NULL)
{
free_var(curvar);
curvar->value = (Datum) 0;
curvar->isnull = true;
}
pfree(values);
pfree(nulls);
if (curname)
pfree(curname);
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
return rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
* exec_stmt_exit Implements EXIT and CONTINUE
*
* This begins the process of exiting / restarting a loop.
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_exit(PLpgSQL_execstate *estate, PLpgSQL_stmt_exit *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
* If the exit / continue has a condition, evaluate it
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (stmt->cond != NULL)
{
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
bool value;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
bool isnull;
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
value = exec_eval_boolean(estate, stmt->cond, &isnull);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
if (isnull || value == false)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
estate->exitlabel = stmt->label;
Add a CONTINUE statement to PL/PgSQL, which can be used to begin the next iteration of a loop. Update documentation and add regression tests. Patch from Pavel Stehule, reviewed by Neil Conway.
2005-06-22 03:35:03 +02:00
if (stmt->is_exit)
return PLPGSQL_RC_EXIT;
else
return PLPGSQL_RC_CONTINUE;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_stmt_return Evaluate an expression and start
* returning from the function.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_return(PLpgSQL_execstate *estate, PLpgSQL_stmt_return *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
/*
* If processing a set-returning PL/PgSQL function, the final RETURN
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* indicates that the function is finished producing tuples. The rest of
* the work will be done at the top level.
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
*/
if (estate->retisset)
return PLPGSQL_RC_RETURN;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
/* initialize for null result (possibly a tuple) */
estate->retval = (Datum) 0;
estate->rettupdesc = NULL;
estate->retisnull = true;
if (stmt->retvarno >= 0)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
PLpgSQL_datum *retvar = estate->datums[stmt->retvarno];
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
switch (retvar->dtype)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
case PLPGSQL_DTYPE_VAR:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_var *var = (PLpgSQL_var *) retvar;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
estate->retval = var->value;
estate->retisnull = var->isnull;
estate->rettype = var->datatype->typoid;
}
break;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
case PLPGSQL_DTYPE_REC:
{
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
PLpgSQL_rec *rec = (PLpgSQL_rec *) retvar;
if (HeapTupleIsValid(rec->tup))
{
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
estate->retval = PointerGetDatum(rec->tup);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
estate->rettupdesc = rec->tupdesc;
estate->retisnull = false;
}
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
}
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
break;
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
case PLPGSQL_DTYPE_ROW:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_row *row = (PLpgSQL_row *) retvar;
Assert(row->rowtupdesc);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
estate->retval =
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
PointerGetDatum(make_tuple_from_row(estate, row,
row->rowtupdesc));
if (DatumGetPointer(estate->retval) == NULL) /* should not happen */
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
elog(ERROR, "row not compatible with its own tupdesc");
estate->rettupdesc = row->rowtupdesc;
estate->retisnull = false;
}
break;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
default:
elog(ERROR, "unrecognized dtype: %d", retvar->dtype);
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
}
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
return PLPGSQL_RC_RETURN;
}
if (stmt->expr != NULL)
{
if (estate->retistuple)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
exec_run_select(estate, stmt->expr, 1, NULL);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_processed > 0)
{
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
estate->retval = PointerGetDatum(estate->eval_tuptable->vals[0]);
Fix coredump in plpgsql when trying to return a rowtype result. Need to return a TupleTableSlot, not just a bare tuple.
2001-11-05 20:41:56 +01:00
estate->rettupdesc = estate->eval_tuptable->tupdesc;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
estate->retisnull = false;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
else
{
/* Normal case for scalar results */
estate->retval = exec_eval_expr(estate, stmt->expr,
&(estate->retisnull),
&(estate->rettype));
}
Allow plpgsql functions to omit RETURN command when the function returns output parameters or VOID or a set. There seems no particular reason to insist on a RETURN in these cases, since the function return value is determined by other elements anyway. Per recent discussion.
2005-04-07 16:53:04 +02:00
return PLPGSQL_RC_RETURN;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Allow plpgsql functions to omit RETURN command when the function returns output parameters or VOID or a set. There seems no particular reason to insist on a RETURN in these cases, since the function return value is determined by other elements anyway. Per recent discussion.
2005-04-07 16:53:04 +02:00
/*
* Special hack for function returning VOID: instead of NULL, return a
* non-null VOID value. This is of dubious importance but is kept for
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* backwards compatibility. Note that the only other way to get here is
* to have written "RETURN NULL" in a function returning tuple.
Allow plpgsql functions to omit RETURN command when the function returns output parameters or VOID or a set. There seems no particular reason to insist on a RETURN in these cases, since the function return value is determined by other elements anyway. Per recent discussion.
2005-04-07 16:53:04 +02:00
*/
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (estate->fn_rettype == VOIDOID)
{
estate->retval = (Datum) 0;
estate->retisnull = false;
estate->rettype = VOIDOID;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_RETURN;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
This patch makes a minor cleanup to the implementation of PERFORM in PL/PgSQL. Previously, it had been bundled together with the assign statement implementation, for some reason that wasn't clear to me (they certainly don't share any code with one another). So I separated them and made PERFORM a statement like any other. No changes in functionality. Along the way, I added some regression tests for PERFORM, added a bunch more SGML tags to the PL/PgSQL docs, and removed an obsolete comment relating to the implementation of RETURN NEXT. Neil Conway
2002-11-10 01:35:58 +01:00
/* ----------
* exec_stmt_return_next Evaluate an expression and add it to the
* list of tuples returned by the current
* SRF.
* ----------
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_return_next(PLpgSQL_execstate *estate,
PLpgSQL_stmt_return_next *stmt)
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
{
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
TupleDesc tupdesc;
int natts;
MemoryContext oldcxt;
HeapTuple tuple = NULL;
bool free_tuple = false;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (!estate->retisset)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot use RETURN NEXT in a non-SETOF function")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (estate->tuple_store == NULL)
exec_init_tuple_store(estate);
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
/* rettupdesc will be filled by exec_init_tuple_store */
tupdesc = estate->rettupdesc;
pgindent run.
2002-09-04 22:31:48 +02:00
natts = tupdesc->natts;
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
if (stmt->retvarno >= 0)
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
{
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
PLpgSQL_datum *retvar = estate->datums[stmt->retvarno];
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
switch (retvar->dtype)
{
case PLPGSQL_DTYPE_VAR:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_var *var = (PLpgSQL_var *) retvar;
Datum retval = var->value;
bool isNull = var->isnull;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
if (natts != 1)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("wrong result type supplied in RETURN NEXT")));
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
/* coerce type if needed */
retval = exec_simple_cast_value(retval,
var->datatype->typoid,
tupdesc->attrs[0]->atttypid,
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
tupdesc->attrs[0]->atttypmod,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
isNull);
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
oldcxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
tuplestore_putvalues(estate->tuple_store, tupdesc,
&retval, &isNull);
MemoryContextSwitchTo(oldcxt);
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
}
break;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
case PLPGSQL_DTYPE_REC:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_rec *rec = (PLpgSQL_rec *) retvar;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
if (!HeapTupleIsValid(rec->tup))
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
errdetail("The tuple structure of a not-yet-assigned"
" record is indeterminate.")));
validate_tupdesc_compat(tupdesc, rec->tupdesc,
gettext_noop("wrong record type supplied "
"in RETURN NEXT"));
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
tuple = rec->tup;
}
break;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
case PLPGSQL_DTYPE_ROW:
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
{
PLpgSQL_row *row = (PLpgSQL_row *) retvar;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
tuple = make_tuple_from_row(estate, row, tupdesc);
if (tuple == NULL)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("wrong record type supplied in RETURN NEXT")));
free_tuple = true;
}
break;
plpgsql does OUT parameters, as per my proposal a few weeks ago.
2005-04-05 08:22:17 +02:00
default:
elog(ERROR, "unrecognized dtype: %d", retvar->dtype);
break;
}
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
}
else if (stmt->expr)
{
pgindent run.
2002-09-04 22:31:48 +02:00
Datum retval;
bool isNull;
Oid rettype;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
if (natts != 1)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("wrong result type supplied in RETURN NEXT")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
retval = exec_eval_expr(estate,
stmt->expr,
&isNull,
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
&rettype);
/* coerce type if needed */
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
retval = exec_simple_cast_value(retval,
rettype,
tupdesc->attrs[0]->atttypid,
tupdesc->attrs[0]->atttypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
isNull);
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
Add a new tuplestore API function, tuplestore_putvalues(). This is identical to tuplestore_puttuple(), except it operates on arrays of Datums + nulls rather than a fully-formed HeapTuple. In several places that use the tuplestore API, this means we can avoid creating a HeapTuple altogether, saving a copy.
2008-03-25 20:26:54 +01:00
oldcxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
tuplestore_putvalues(estate->tuple_store, tupdesc,
&retval, &isNull);
MemoryContextSwitchTo(oldcxt);
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
exec_eval_cleanup(estate);
}
else
{
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RETURN NEXT must have a parameter")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
}
if (HeapTupleIsValid(tuple))
{
oldcxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
tuplestore_puttuple(estate->tuple_store, tuple);
MemoryContextSwitchTo(oldcxt);
if (free_tuple)
heap_freetuple(tuple);
}
return PLPGSQL_RC_OK;
}
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
/* ----------
* exec_stmt_return_query Evaluate a query and add it to the
* list of tuples returned by the current
* SRF.
* ----------
*/
static int
exec_stmt_return_query(PLpgSQL_execstate *estate,
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
PLpgSQL_stmt_return_query *stmt)
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Portal portal;
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
if (!estate->retisset)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("cannot use RETURN QUERY in a non-SETOF function")));
if (estate->tuple_store == NULL)
exec_init_tuple_store(estate);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
if (stmt->query != NULL)
{
/* static query */
exec_run_select(estate, stmt->query, 0, &portal);
}
else
{
/* RETURN QUERY EXECUTE */
Assert(stmt->dynquery != NULL);
portal = exec_dynquery_with_params(estate, stmt->dynquery,
stmt->params);
}
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
validate_tupdesc_compat(estate->rettupdesc, portal->tupDesc,
gettext_noop("structure of query does not match "
"function result type"));
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
while (true)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
MemoryContext old_cxt;
int i;
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
SPI_cursor_fetch(portal, true, 50);
if (SPI_processed == 0)
break;
old_cxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
for (i = 0; i < SPI_processed; i++)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
HeapTuple tuple = SPI_tuptable->vals[i];
Implement RETURN QUERY for PL/PgSQL. This provides some convenient syntax sugar for PL/PgSQL set-returning functions that want to return the result of evaluating a query; it should also be more efficient than repeated RETURN NEXT statements. Based on an earlier patch from Pavel Stehule.
2007-07-25 06:19:09 +02:00
tuplestore_puttuple(estate->tuple_store, tuple);
}
MemoryContextSwitchTo(old_cxt);
SPI_freetuptable(SPI_tuptable);
}
SPI_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
return PLPGSQL_RC_OK;
}
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_init_tuple_store(PLpgSQL_execstate *estate)
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
{
ReturnSetInfo *rsi = estate->rsi;
MemoryContext oldcxt;
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
/*
* Check caller can handle a set result in the way we want
*/
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
if (!rsi || !IsA(rsi, ReturnSetInfo) ||
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
(rsi->allowedModes & SFRM_Materialize) == 0 ||
rsi->expectedDesc == NULL)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("set-valued function called in context that cannot accept a set")));
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
estate->tuple_store_cxt = rsi->econtext->ecxt_per_query_memory;
oldcxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
Be more tense about not creating tuplestores with randomAccess = true unless backwards scan could actually happen. In particular, pass a flag to materialize-mode SRFs that tells them whether they need to require random access. In passing, also suppress unneeded backward-scan overhead for a Portal's holdStore tuplestore. Per my proposal about reducing I/O costs for tuplestores.
2008-10-29 01:00:39 +01:00
estate->tuple_store =
tuplestore_begin_heap(rsi->allowedModes & SFRM_Materialize_Random,
false, work_mem);
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
MemoryContextSwitchTo(oldcxt);
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
estate->rettupdesc = rsi->expectedDesc;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
* exec_stmt_raise Build a message and throw it with elog()
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_raise(PLpgSQL_execstate *estate, PLpgSQL_stmt_raise *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
int err_code = 0;
char *condname = NULL;
char *err_message = NULL;
char *err_detail = NULL;
char *err_hint = NULL;
ListCell *lc;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
/* RAISE with no parameters: re-throw current exception */
if (stmt->condname == NULL && stmt->message == NULL &&
stmt->options == NIL)
return PLPGSQL_RC_RERAISE;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
if (stmt->condname)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
err_code = plpgsql_recognize_err_condition(stmt->condname, true);
condname = pstrdup(stmt->condname);
}
if (stmt->message)
{
PLpgSQL_dstring ds;
ListCell *current_param;
char *cp;
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
plpgsql_dstring_init(&ds);
current_param = list_head(stmt->params);
for (cp = stmt->message; *cp; cp++)
{
/*
* Occurrences of a single % are replaced by the next parameter's
* external representation. Double %'s are converted to one %.
*/
if (cp[0] == '%')
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
Oid paramtypeid;
Datum paramvalue;
bool paramisnull;
char *extval;
if (cp[1] == '%')
{
plpgsql_dstring_append_char(&ds, cp[1]);
cp++;
continue;
}
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
if (current_param == NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("too few parameters specified for RAISE")));
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
paramvalue = exec_eval_expr(estate,
(PLpgSQL_expr *) lfirst(current_param),
&paramisnull,
&paramtypeid);
Allow the parameters to PL/PgSQL's RAISE statement to be expressions, instead of just scalar variables. Add regression tests and update the documentation. Along the way, remove some redundant error checking code from exec_stmt_perform(). Original patch from Pavel Stehule, reworked by Neil Conway.
2005-06-14 08:43:15 +02:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
if (paramisnull)
extval = "<NULL>";
else
extval = convert_value_to_string(paramvalue, paramtypeid);
plpgsql_dstring_append(&ds, extval);
current_param = lnext(current_param);
exec_eval_cleanup(estate);
}
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
else
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
plpgsql_dstring_append_char(&ds, cp[0]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
/*
* If more parameters were specified than were required to process the
* format string, throw an error
*/
if (current_param != NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("too many parameters specified for RAISE")));
err_message = plpgsql_dstring_get(&ds);
/* No dstring_free here, the pfree(err_message) does it */
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
foreach(lc, stmt->options)
{
PLpgSQL_raise_option *opt = (PLpgSQL_raise_option *) lfirst(lc);
Datum optionvalue;
bool optionisnull;
Oid optiontypeid;
char *extval;
optionvalue = exec_eval_expr(estate, opt->expr,
&optionisnull,
&optiontypeid);
if (optionisnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("RAISE statement option cannot be NULL")));
extval = convert_value_to_string(optionvalue, optiontypeid);
switch (opt->opt_type)
{
case PLPGSQL_RAISEOPTION_ERRCODE:
if (err_code)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE option already specified: %s",
"ERRCODE")));
err_code = plpgsql_recognize_err_condition(extval, true);
condname = pstrdup(extval);
break;
case PLPGSQL_RAISEOPTION_MESSAGE:
if (err_message)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE option already specified: %s",
"MESSAGE")));
err_message = pstrdup(extval);
break;
case PLPGSQL_RAISEOPTION_DETAIL:
if (err_detail)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE option already specified: %s",
"DETAIL")));
err_detail = pstrdup(extval);
break;
case PLPGSQL_RAISEOPTION_HINT:
if (err_hint)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("RAISE option already specified: %s",
"HINT")));
err_hint = pstrdup(extval);
break;
default:
elog(ERROR, "unrecognized raise option: %d", opt->opt_type);
}
exec_eval_cleanup(estate);
}
/* Default code if nothing specified */
if (err_code == 0 && stmt->elog_level >= ERROR)
err_code = ERRCODE_RAISE_EXCEPTION;
/* Default error message if nothing specified */
if (err_message == NULL)
{
if (condname)
{
err_message = condname;
condname = NULL;
}
else
err_message = pstrdup(unpack_sql_state(err_code));
}
This patch changes makes some significant changes to how compilation and parsing work in PL/PgSQL: - memory management is now done via palloc(). The compiled representation of each function now has its own memory context. Therefore, the storage consumed by a function can be reclaimed via MemoryContextDelete(). During compilation, the CurrentMemoryContext is the function's memory context. This means that a palloc() is sufficient to allocate memory that will have the same lifetime as the function itself. As a result, code invoked during compilation should be careful to pfree() temporary allocations to avoid leaking memory. Since a lot of the code in the backend is not careful about releasing palloc'ed memory, that means we should switch into a temporary memory context before invoking backend functions. A temporary context appropriate for such allocations is `compile_tmp_cxt'. - The ability to use palloc() allows us to simply a lot of the code in the parser. Rather than representing lists of elements via ad hoc linked lists or arrays, we can use the List type. Rather than doing malloc followed by memset(0), we can just use palloc0(). - We now check that the user has supplied the right number of parameters to a RAISE statement. Supplying either too few or too many results in an error (at runtime). - PL/PgSQL's parser needs to accept arbitrary SQL statements. Since we do not want to duplicate the SQL grammar in the PL/PgSQL grammar, this means we need to be quite lax in what the PL/PgSQL grammar considers a "SQL statement". This can lead to misleading behavior if there is a syntax error in the function definition, since we assume a malformed PL/PgSQL construct is a SQL statement. Furthermore, these errors were only detected at runtime (when we tried to execute the alleged "SQL statement" via SPI). To rectify this, the patch changes the parser to invoke the main SQL parser when it sees a string it believes to be a SQL expression. This means that synctically-invalid SQL will be rejected during the compilation of the PL/PgSQL function. This is only done when compiling for "validation" purposes (i.e. at CREATE FUNCTION time), so it should not impose a runtime overhead. - Fixes for the various buffer overruns I've patched in stable branches in the past few weeks. I've rewritten code where I thought it was warranted (unlike the patches applied to older branches, which were minimally invasive). - Various other minor changes and cleanups. - Updates to the regression tests.
2005-02-22 08:18:27 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
* Throw the error (may or may not come back)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
pgindent run.
2003-08-04 02:43:34 +02:00
estate->err_text = raise_skip_msg; /* suppress traceback of raise */
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
ereport(stmt->elog_level,
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
(err_code ? errcode(err_code) : 0,
errmsg_internal("%s", err_message),
(err_detail != NULL) ? errdetail(err_detail) : 0,
(err_hint != NULL) ? errhint(err_hint) : 0));
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_text = NULL; /* un-suppress... */
Improve plpgsql's RAISE command. It is now possible to attach DETAIL and HINT fields to a user-thrown error message, and to specify the SQLSTATE error code to use. The syntax has also been tweaked so that the Oracle-compatible case "RAISE exception_name" works (though you won't get a very nice error message if you just write that much). Lastly, support the Oracle-compatible syntax "RAISE" with no parameters to re-throw the current error from within an EXCEPTION block. In passing, allow the syntax SQLSTATE 'nnnnn' within EXCEPTION lists, so that there is a way to trap errors with custom SQLSTATE codes. Pavel Stehule and Tom Lane
2008-05-14 00:10:30 +02:00
if (condname != NULL)
pfree(condname);
if (err_message != NULL)
pfree(err_message);
if (err_detail != NULL)
pfree(err_detail);
if (err_hint != NULL)
pfree(err_hint);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* ----------
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
* Initialize a mostly empty execution state
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
* ----------
*/
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
plpgsql_estate_setup(PLpgSQL_execstate *estate,
PLpgSQL_function *func,
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
ReturnSetInfo *rsi)
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
{
estate->retval = (Datum) 0;
estate->retisnull = true;
estate->rettype = InvalidOid;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
estate->fn_rettype = func->fn_rettype;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
estate->retistuple = func->fn_retistuple;
estate->retisset = func->fn_retset;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
estate->readonly_func = func->fn_readonly;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
estate->rettupdesc = NULL;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
estate->exitlabel = NULL;
PL/pgSQL functions can return sets. Neil Conway's patch, modified so that the functionality is available to anyone via ReturnSetInfo, rather than hard-wiring it to PL/pgSQL.
2002-08-30 02:28:41 +02:00
estate->tuple_store = NULL;
estate->tuple_store_cxt = NULL;
estate->rsi = rsi;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
estate->trig_nargs = 0;
estate->trig_argv = NULL;
estate->found_varno = func->found_varno;
estate->ndatums = func->ndatums;
estate->datums = palloc(sizeof(PLpgSQL_datum *) * estate->ndatums);
/* caller is expected to fill the datums array */
estate->eval_tuptable = NULL;
estate->eval_processed = 0;
estate->eval_lastoid = InvalidOid;
Infrastructure for upgraded error reporting mechanism. elog.c is rewritten and the protocol is changed, but most elog calls are still elog calls. Also, we need to contemplate mechanisms for controlling all this functionality --- eg, how much stuff should appear in the postmaster log? And what API should libpq expose for it?
2003-04-24 23:16:45 +02:00
estate->err_func = func;
estate->err_stmt = NULL;
estate->err_text = NULL;
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
/*
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* Create an EState and ExprContext for evaluation of simple expressions.
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
*/
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
plpgsql_create_econtext(estate);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Let the plugin see this function before we initialize any local
* PL/pgSQL variables - note that we also give the plugin a few function
* pointers so it can call back into PL/pgSQL for doing things like
* variable assignments and stack traces
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
*/
if (*plugin_ptr)
{
(*plugin_ptr)->error_callback = plpgsql_exec_error_callback;
(*plugin_ptr)->assign_expr = exec_assign_expr;
if ((*plugin_ptr)->func_setup)
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
((*plugin_ptr)->func_setup) (estate, func);
Add hooks to allow debugging and performance measurement plugins to instrument PL/pgSQL. Korry Douglas
2006-08-15 21:01:17 +02:00
}
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
}
/* ----------
* Release temporary memory used by expression/subselect evaluation
*
* NB: the result of the evaluation is no longer valid after this is done,
* unless it is a pass-by-value datatype.
* ----------
*/
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_cleanup(PLpgSQL_execstate *estate)
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
{
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
/* Clear result of a full SPI_execute */
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_tuptable != NULL)
SPI_freetuptable(estate->eval_tuptable);
estate->eval_tuptable = NULL;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
/* Clear result of exec_eval_simple_expr (but keep the econtext) */
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_econtext != NULL)
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
ResetExprContext(estate->eval_econtext);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
/* ----------
* Generate a prepared plan
* ----------
*/
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_prepare_plan(PLpgSQL_execstate *estate,
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
PLpgSQL_expr *expr, int cursorOptions)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
{
int i;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
SPIPlanPtr plan;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Oid *argtypes;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* We need a temporary argtypes array to load with data. (The finished
* plan structure will contain a copy of it.)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Tweak palloc/repalloc to allow zero bytes to be requested, as per recent proposal. Eliminate several dozen now-unnecessary hacks to avoid palloc(0). (It's likely there are more that I didn't find.)
2004-06-05 21:48:09 +02:00
argtypes = (Oid *) palloc(expr->nparams * sizeof(Oid));
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
for (i = 0; i < expr->nparams; i++)
{
pgindent run.
2003-08-04 02:43:34 +02:00
Datum paramval;
bool paramisnull;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
exec_eval_datum(estate, estate->datums[expr->params[i]],
InvalidOid,
&argtypes[i], &paramval, &paramisnull);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
* Generate and save the plan
*/
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
plan = SPI_prepare_cursor(expr->query, expr->nparams, argtypes,
cursorOptions);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
if (plan == NULL)
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
{
/* Some SPI errors deserve specific error messages */
switch (SPI_result)
{
case SPI_ERROR_COPY:
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot COPY to/from client in PL/pgSQL")));
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
case SPI_ERROR_TRANSACTION:
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cannot begin/end transactions in PL/pgSQL"),
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
errhint("Use a BEGIN block with an EXCEPTION clause instead.")));
default:
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
elog(ERROR, "SPI_prepare_cursor failed for \"%s\": %s",
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
expr->query, SPI_result_code_string(SPI_result));
}
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
expr->plan = SPI_saveplan(plan);
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
SPI_freeplan(plan);
plan = expr->plan;
expr->plan_argtypes = plan->argtypes;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
exec_simple_check_plan(expr);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
pfree(argtypes);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
* exec_stmt_execsql Execute an SQL statement (possibly with INTO).
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_execsql(PLpgSQL_execstate *estate,
PLpgSQL_stmt_execsql *stmt)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum *values;
char *nulls;
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
long tcount;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int rc;
PLpgSQL_expr *expr = stmt->sqlstmt;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* On the first call for this statement generate the plan, and detect
* whether the statement is INSERT/UPDATE/DELETE
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (expr->plan == NULL)
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
{
ListCell *l;
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
exec_prepare_plan(estate, expr, 0);
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
stmt->mod_stmt = false;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
foreach(l, expr->plan->plancache_list)
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
{
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
CachedPlanSource *plansource = (CachedPlanSource *) lfirst(l);
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
ListCell *l2;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
foreach(l2, plansource->plan->stmt_list)
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
{
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
PlannedStmt *p = (PlannedStmt *) lfirst(l2);
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
if (IsA(p, PlannedStmt) &&
p->canSetTag)
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
{
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
if (p->commandType == CMD_INSERT ||
p->commandType == CMD_UPDATE ||
p->commandType == CMD_DELETE)
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
stmt->mod_stmt = true;
}
}
}
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
* Now build up the values and nulls arguments for SPI_execute_plan()
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
eval_expr_params(estate, expr, &values, &nulls);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* If we have INTO, then we only need one row back ... but if we have INTO
* STRICT, ask for two rows, so that we can verify the statement returns
* only one. INSERT/UPDATE/DELETE are always treated strictly. Without
* INTO, just run the statement to completion (tcount = 0).
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* We could just ask for two rows always when using INTO, but there are
* some cases where demanding the extra row costs significant time, eg by
* forcing completion of a sequential scan. So don't do it unless we need
* to enforce strictness.
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
*/
if (stmt->into)
{
if (stmt->strict || stmt->mod_stmt)
tcount = 2;
else
tcount = 1;
}
else
tcount = 0;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Execute the plan
*/
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
rc = SPI_execute_plan(expr->plan, values, nulls,
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
estate->readonly_func, tcount);
/*
* Check for error, and set FOUND if appropriate (for historical reasons
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* we set FOUND only for certain query types). Also Assert that we
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
* identified the statement type the same as SPI did.
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (rc)
{
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
case SPI_OK_SELECT:
Assert(!stmt->mod_stmt);
exec_set_found(estate, (SPI_processed != 0));
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
break;
FOUND patch was a bit over-enthusiastic: SQL commands that are not INSERT, UPDATE, or DELETE shouldn't change FOUND. IMHO anyway. Also, try to make documentation a little clearer.
2002-08-29 06:12:03 +02:00
case SPI_OK_INSERT:
case SPI_OK_UPDATE:
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
case SPI_OK_DELETE:
Add new return codes SPI_OK_INSERT_RETURNING etc to the SPI API. Fix all the standard PLs to be able to return tuples from FOO_RETURNING statements as well as utility statements that return tuples. Also, fix oversight that SPI_processed wasn't set for a utility statement returning tuples. Per recent discussion.
2006-08-28 01:47:58 +02:00
case SPI_OK_INSERT_RETURNING:
case SPI_OK_UPDATE_RETURNING:
case SPI_OK_DELETE_RETURNING:
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
Assert(stmt->mod_stmt);
exec_set_found(estate, (SPI_processed != 0));
break;
pgindent run.
2002-09-04 22:31:48 +02:00
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
case SPI_OK_SELINTO:
case SPI_OK_UTILITY:
Assert(!stmt->mod_stmt);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
default:
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
elog(ERROR, "SPI_execute_plan failed executing query \"%s\": %s",
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
expr->query, SPI_result_code_string(rc));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/* All variants should save result info for GET DIAGNOSTICS */
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
estate->eval_processed = SPI_processed;
estate->eval_lastoid = SPI_lastoid;
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/* Process INTO if present */
if (stmt->into)
{
SPITupleTable *tuptab = SPI_tuptable;
uint32 n = SPI_processed;
PLpgSQL_rec *rec = NULL;
PLpgSQL_row *row = NULL;
/* If the statement did not return a tuple table, complain */
if (tuptab == NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
errmsg("INTO used with a command that cannot return data")));
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/* Determine if we assign to a record or a row */
if (stmt->rec != NULL)
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->recno]);
else if (stmt->row != NULL)
row = (PLpgSQL_row *) (estate->datums[stmt->row->rowno]);
else
elog(ERROR, "unsupported target");
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* If SELECT ... INTO specified STRICT, and the query didn't find
* exactly one row, throw an error. If STRICT was not specified, then
* allow the query to find any number of rows.
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
*/
if (n == 0)
{
if (stmt->strict)
ereport(ERROR,
(errcode(ERRCODE_NO_DATA_FOUND),
errmsg("query returned no rows")));
/* set the target to NULL(s) */
exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);
}
else
{
if (n > 1 && (stmt->strict || stmt->mod_stmt))
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_ROWS),
errmsg("query returned more than one row")));
/* Put the first result row into the target */
exec_move_row(estate, rec, row, tuptab->vals[0], tuptab->tupdesc);
}
/* Clean up */
SPI_freetuptable(SPI_tuptable);
}
else
{
/* If the statement returned a tuple table, complain */
if (SPI_tuptable != NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("query has no destination for result data"),
(rc == SPI_OK_SELECT) ? errhint("If you want to discard the results of a SELECT, use PERFORM instead.") : 0));
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
pfree(values);
pfree(nulls);
return PLPGSQL_RC_OK;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
/* ----------
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
* exec_stmt_dynexecute Execute a dynamic SQL query
* (possibly with INTO).
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_dynexecute(PLpgSQL_execstate *estate,
PLpgSQL_stmt_dynexecute *stmt)
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
{
Datum query;
bool isnull = false;
Oid restype;
char *querystr;
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
int exec_res;
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* First we evaluate the string expression after the EXECUTE keyword. Its
* result is the querystring we have to execute.
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
*/
query = exec_eval_expr(estate, stmt->query, &isnull, &restype);
if (isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("cannot EXECUTE a null querystring")));
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
/* Get the C-String representation */
querystr = convert_value_to_string(query, restype);
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
Change SearchSysCache coding conventions so that a reference count is maintained for each cache entry. A cache entry will not be freed until the matching ReleaseSysCache call has been executed. This eliminates worries about cache entries getting dropped while still in use. See my posting to pg-hackers of even date for more info.
2000-11-16 23:30:52 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
* Execute the query without preparing a saved plan.
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
*/
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
if (stmt->params)
{
PreparedParamsData *ppd;
ppd = exec_eval_using_params(estate, stmt->params);
exec_res = SPI_execute_with_args(querystr,
ppd->nargs, ppd->types,
ppd->values, ppd->nulls,
estate->readonly_func, 0);
free_params_data(ppd);
}
else
exec_res = SPI_execute(querystr, estate->readonly_func, 0);
Add support for an optional INTO clause to PL/PgSQL's EXECUTE command. This allows the result of executing a SELECT to be assigned to a row variable, record variable, or list of scalars. Docs and regression tests updated. Per Pavel Stehule, improvements and cleanup by Neil Conway.
2005-06-07 04:47:23 +02:00
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
switch (exec_res)
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
{
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
case SPI_OK_SELECT:
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
case SPI_OK_INSERT:
case SPI_OK_UPDATE:
case SPI_OK_DELETE:
Add new return codes SPI_OK_INSERT_RETURNING etc to the SPI API. Fix all the standard PLs to be able to return tuples from FOO_RETURNING statements as well as utility statements that return tuples. Also, fix oversight that SPI_processed wasn't set for a utility statement returning tuples. Per recent discussion.
2006-08-28 01:47:58 +02:00
case SPI_OK_INSERT_RETURNING:
case SPI_OK_UPDATE_RETURNING:
case SPI_OK_DELETE_RETURNING:
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
case SPI_OK_UTILITY:
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
break;
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
case 0:
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
/*
* Also allow a zero return, which implies the querystring
Clean up some unnecessary fragility in EXECUTE command.
2001-01-04 03:38:02 +01:00
* contained no commands.
*/
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
break;
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, rather than executing the INTO clause with non-plpgsql semantics as it was doing for the last few weeks/months. This keeps our options open for making it do the right plpgsql-ish thing in future without creating a backwards compatibility problem. There is no loss of functionality since people can get the same behavior with CREATE TABLE AS.
2001-02-09 01:14:26 +01:00
case SPI_OK_SELINTO:
pgindent run. Make it all clean.
2001-03-22 05:01:46 +01:00
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, rather than executing the INTO clause with non-plpgsql semantics as it was doing for the last few weeks/months. This keeps our options open for making it do the right plpgsql-ish thing in future without creating a backwards compatibility problem. There is no loss of functionality since people can get the same behavior with CREATE TABLE AS.
2001-02-09 01:14:26 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We want to disallow SELECT INTO for now, because its behavior
* is not consistent with SELECT INTO in a normal plpgsql context.
* (We need to reimplement EXECUTE to parse the string as a
* plpgsql command, not just feed it to SPI_execute.) However,
* CREATE AS should be allowed ... and since it produces the same
* parsetree as SELECT INTO, there's no way to tell the difference
* except to look at the source text. Wotta kluge!
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, rather than executing the INTO clause with non-plpgsql semantics as it was doing for the last few weeks/months. This keeps our options open for making it do the right plpgsql-ish thing in future without creating a backwards compatibility problem. There is no loss of functionality since people can get the same behavior with CREATE TABLE AS.
2001-02-09 01:14:26 +01:00
*/
pgindent run.
2002-09-04 22:31:48 +02:00
{
char *ptr;
Re-allow CREATE AS (but not SELECT INTO) in EXECUTE.
2002-03-25 08:41:10 +01:00
pgindent run.
2002-09-04 22:31:48 +02:00
for (ptr = querystr; *ptr; ptr++)
Fix bugs in plpgsql and ecpg caused by assuming that isspace() would only return true for exactly the characters treated as whitespace by their flex scanners. Per report from Victor Snezhko and subsequent investigation. Also fix a passel of unsafe usages of <ctype.h> functions, that is, ye olde char-vs-unsigned-char issue. I won't miss <ctype.h> when we are finally able to stop using it.
2006-09-22 23:39:58 +02:00
if (!scanner_isspace(*ptr))
pgindent run.
2002-09-04 22:31:48 +02:00
break;
if (*ptr == 'S' || *ptr == 's')
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("EXECUTE of SELECT ... INTO is not implemented yet")));
pgindent run.
2002-09-04 22:31:48 +02:00
break;
}
EXECUTE of a SELECT ... INTO now draws a 'not implemented' error, rather than executing the INTO clause with non-plpgsql semantics as it was doing for the last few weeks/months. This keeps our options open for making it do the right plpgsql-ish thing in future without creating a backwards compatibility problem. There is no loss of functionality since people can get the same behavior with CREATE TABLE AS.
2001-02-09 01:14:26 +01:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/* Some SPI errors deserve specific error messages */
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
case SPI_ERROR_COPY:
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot COPY to/from client in PL/pgSQL")));
case SPI_ERROR_TRANSACTION:
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot begin/end transactions in PL/pgSQL"),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errhint("Use a BEGIN block with an EXCEPTION clause instead.")));
Give a more specific error message for "you can't do that" error cases in plpgsql, particularly trying to begin/end/rollback a transaction.
2004-08-13 20:47:56 +02:00
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
default:
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
elog(ERROR, "SPI_execute failed executing query \"%s\": %s",
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
querystr, SPI_result_code_string(exec_res));
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
break;
}
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* Save result info for GET DIAGNOSTICS */
estate->eval_processed = SPI_processed;
estate->eval_lastoid = SPI_lastoid;
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/* Process INTO if present */
if (stmt->into)
{
SPITupleTable *tuptab = SPI_tuptable;
uint32 n = SPI_processed;
PLpgSQL_rec *rec = NULL;
PLpgSQL_row *row = NULL;
/* If the statement did not return a tuple table, complain */
if (tuptab == NULL)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
errmsg("INTO used with a command that cannot return data")));
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
/* Determine if we assign to a record or a row */
if (stmt->rec != NULL)
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->recno]);
else if (stmt->row != NULL)
row = (PLpgSQL_row *) (estate->datums[stmt->row->rowno]);
else
elog(ERROR, "unsupported target");
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* If SELECT ... INTO specified STRICT, and the query didn't find
* exactly one row, throw an error. If STRICT was not specified, then
* allow the query to find any number of rows.
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
*/
if (n == 0)
{
if (stmt->strict)
ereport(ERROR,
(errcode(ERRCODE_NO_DATA_FOUND),
errmsg("query returned no rows")));
/* set the target to NULL(s) */
exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);
}
else
{
if (n > 1 && stmt->strict)
ereport(ERROR,
(errcode(ERRCODE_TOO_MANY_ROWS),
errmsg("query returned more than one row")));
/* Put the first result row into the target */
exec_move_row(estate, rec, row, tuptab->vals[0], tuptab->tupdesc);
}
}
else
{
/*
* It might be a good idea to raise an error if the query returned
* tuples that are being ignored, but historically we have not done
* that.
*/
}
/* Release any result from SPI_execute, as well as the querystring */
SPI_freetuptable(SPI_tuptable);
pfree(querystr);
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
return PLPGSQL_RC_OK;
}
/* ----------
* exec_stmt_dynfors Execute a dynamic query, assign each
* tuple to a record or row and
* execute a group of statements
* for it.
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_dynfors(PLpgSQL_execstate *estate, PLpgSQL_stmt_dynfors *stmt)
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
{
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Portal portal;
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
int rc;
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
portal = exec_dynquery_with_params(estate, stmt->query, stmt->params);
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/*
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
* Execute the loop
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
rc = exec_for_query(estate, (PLpgSQL_stmt_forq *) stmt, portal, true);
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
/*
* Close the implicit cursor
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
*/
SPI_cursor_close(portal);
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
return rc;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
}
/* ----------
* exec_stmt_open Execute an OPEN cursor statement
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_open(PLpgSQL_execstate *estate, PLpgSQL_stmt_open *stmt)
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
{
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
PLpgSQL_var *curvar;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
char *curname = NULL;
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
PLpgSQL_expr *query;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Portal portal;
Datum *values;
char *nulls;
bool isnull;
/* ----------
* Get the cursor variable and if it has an assigned name, check
* that it's not in use currently.
* ----------
*/
curvar = (PLpgSQL_var *) (estate->datums[stmt->curvar]);
if (!curvar->isnull)
{
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
curname = TextDatumGetCString(curvar->value);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (SPI_cursor_find(curname) != NULL)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_CURSOR),
errmsg("cursor \"%s\" already in use", curname)));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
}
/* ----------
* Process the OPEN according to it's type.
* ----------
*/
if (stmt->query != NULL)
{
/* ----------
* This is an OPEN refcursor FOR SELECT ...
*
* We just make sure the query is planned. The real work is
* done downstairs.
* ----------
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
*/
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
query = stmt->query;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (query->plan == NULL)
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
exec_prepare_plan(estate, query, stmt->cursor_options);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
}
else if (stmt->dynquery != NULL)
{
/* ----------
* This is an OPEN refcursor FOR EXECUTE ...
* ----------
*/
Datum queryD;
Oid restype;
char *querystr;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
SPIPlanPtr curplan;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/* ----------
* We evaluate the string expression after the
* EXECUTE keyword. It's result is the querystring we have
* to execute.
* ----------
*/
queryD = exec_eval_expr(estate, stmt->dynquery, &isnull, &restype);
if (isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("cannot EXECUTE a null querystring")));
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
/* Get the C-String representation */
querystr = convert_value_to_string(queryD, restype);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/* ----------
* Now we prepare a query plan for it and open a cursor
* ----------
*/
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
curplan = SPI_prepare_cursor(querystr, 0, NULL, stmt->cursor_options);
Fix within-function memory leaks in the various PLs' interfaces to SPI_prepare: they all save the prepared plan into topCxt, and so the procCxt copy that's actually returned by SPI_prepare ought to be freed. Diagnosis and plpython fix by Nigel Andrews, followup for other PLs by Tom Lane.
2002-10-20 00:10:58 +02:00
if (curplan == NULL)
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
elog(ERROR, "SPI_prepare_cursor failed for \"%s\": %s",
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
querystr, SPI_result_code_string(SPI_result));
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
portal = SPI_cursor_open(curname, curplan, NULL, NULL,
estate->readonly_func);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (portal == NULL)
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
elog(ERROR, "could not open cursor for query \"%s\": %s",
querystr, SPI_result_code_string(SPI_result));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pfree(querystr);
Fix within-function memory leaks in the various PLs' interfaces to SPI_prepare: they all save the prepared plan into topCxt, and so the procCxt copy that's actually returned by SPI_prepare ought to be freed. Diagnosis and plpython fix by Nigel Andrews, followup for other PLs by Tom Lane.
2002-10-20 00:10:58 +02:00
SPI_freeplan(curplan);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* If cursor variable was NULL, store the generated portal name in it
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
if (curname == NULL)
assign_text_var(curvar, portal->name);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
return PLPGSQL_RC_OK;
}
else
{
/* ----------
* This is an OPEN cursor
Fix some problems in new plpgsql cursor operations, found while trying to reverse-engineer documentation for them.
2001-11-16 00:31:09 +01:00
*
* Note: parser should already have checked that statement supplies
* args iff cursor needs them, but we check again to be safe.
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
* ----------
*/
if (stmt->argquery != NULL)
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
{
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/* ----------
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
* OPEN CURSOR with args. We fake a SELECT ... INTO ...
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
* statement to evaluate the args and put 'em into the
* internal row.
* ----------
*/
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
PLpgSQL_stmt_execsql set_args;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Fix some problems in new plpgsql cursor operations, found while trying to reverse-engineer documentation for them.
2001-11-16 00:31:09 +01:00
if (curvar->cursor_explicit_argrow < 0)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("arguments given for cursor without arguments")));
Fix some problems in new plpgsql cursor operations, found while trying to reverse-engineer documentation for them.
2001-11-16 00:31:09 +01:00
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
memset(&set_args, 0, sizeof(set_args));
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
set_args.cmd_type = PLPGSQL_STMT_EXECSQL;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
set_args.lineno = stmt->lineno;
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
set_args.sqlstmt = stmt->argquery;
set_args.into = true;
/* XXX historically this has not been STRICT */
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
set_args.row = (PLpgSQL_row *)
(estate->datums[curvar->cursor_explicit_argrow]);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Support INSERT/UPDATE/DELETE RETURNING in plpgsql, with rowcount checking as per yesterday's proposal. Also make things a tad more orthogonal by adding the recent STRICT addition to EXECUTE INTO. Jonah Harris and Tom Lane
2006-08-14 23:14:42 +02:00
if (exec_stmt_execsql(estate, &set_args) != PLPGSQL_RC_OK)
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
elog(ERROR, "open cursor failed during argument processing");
}
Fix some problems in new plpgsql cursor operations, found while trying to reverse-engineer documentation for them.
2001-11-16 00:31:09 +01:00
else
{
if (curvar->cursor_explicit_argrow >= 0)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("arguments required for cursor")));
Fix some problems in new plpgsql cursor operations, found while trying to reverse-engineer documentation for them.
2001-11-16 00:31:09 +01:00
}
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
query = curvar->cursor_explicit_expr;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (query->plan == NULL)
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
exec_prepare_plan(estate, query, curvar->cursor_options);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
}
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* Now build up the values and nulls arguments for SPI_execute_plan()
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
eval_expr_params(estate, query, &values, &nulls);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
* Open the cursor
*/
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
portal = SPI_cursor_open(curname, query->plan, values, nulls,
estate->readonly_func);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (portal == NULL)
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
elog(ERROR, "could not open cursor: %s",
SPI_result_code_string(SPI_result));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* If cursor variable was NULL, store the generated portal name in it
*/
if (curname == NULL)
assign_text_var(curvar, portal->name);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pfree(values);
pfree(nulls);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (curname)
pfree(curname);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
return PLPGSQL_RC_OK;
}
/* ----------
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
* exec_stmt_fetch Fetch from a cursor into a target, or just
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* move the current position of the cursor
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_fetch(PLpgSQL_execstate *estate, PLpgSQL_stmt_fetch *stmt)
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
{
PLpgSQL_var *curvar = NULL;
PLpgSQL_rec *rec = NULL;
PLpgSQL_row *row = NULL;
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
long how_many = stmt->how_many;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
SPITupleTable *tuptab;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Portal portal;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
char *curname;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
int n;
/* ----------
* Get the portal of the cursor by name
* ----------
*/
curvar = (PLpgSQL_var *) (estate->datums[stmt->curvar]);
if (curvar->isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cursor variable \"%s\" is NULL", curvar->refname)));
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
curname = TextDatumGetCString(curvar->value);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
portal = SPI_cursor_find(curname);
if (portal == NULL)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_CURSOR),
errmsg("cursor \"%s\" does not exist", curname)));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pfree(curname);
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
/* Calculate position for FETCH_RELATIVE or FETCH_ABSOLUTE */
if (stmt->expr)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
bool isnull;
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
/* XXX should be doing this in LONG not INT width */
how_many = exec_eval_integer(estate, stmt->expr, &isnull);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("relative or absolute cursor position is NULL")));
exec_eval_cleanup(estate);
}
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
if (!stmt->is_move)
{
/* ----------
* Determine if we fetch into a record or a row
* ----------
*/
if (stmt->rec != NULL)
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->recno]);
else if (stmt->row != NULL)
row = (PLpgSQL_row *) (estate->datums[stmt->row->rowno]);
else
elog(ERROR, "unsupported target");
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
/* ----------
* Fetch 1 tuple from the cursor
* ----------
*/
SPI_scroll_cursor_fetch(portal, stmt->direction, how_many);
tuptab = SPI_tuptable;
n = SPI_processed;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
/* ----------
* Set the target and the global FOUND variable appropriately.
* ----------
*/
if (n == 0)
{
exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);
exec_set_found(estate, false);
}
else
{
exec_move_row(estate, rec, row, tuptab->vals[0], tuptab->tupdesc);
exec_set_found(estate, true);
}
SPI_freetuptable(tuptab);
Repair memory leak introduced by recent change to make SPI return a tupdesc even with zero tuples returned: some plpgsql routines assumed they didn't need to do SPI_freetuptable() after retrieving no tuples.
2003-03-02 21:45:47 +01:00
}
else
{
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
/* Move the cursor */
SPI_scroll_cursor_move(portal, stmt->direction, how_many);
n = SPI_processed;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Support for MOVE in PL/PgSQL. Initial patch from Magnus, some improvements by Pavel Stehule, and reviewed by Neil Conway.
2007-04-29 03:21:09 +02:00
/* Set the global FOUND variable appropriately. */
exec_set_found(estate, n != 0);
}
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
return PLPGSQL_RC_OK;
}
/* ----------
* exec_stmt_close Close a cursor
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_stmt_close(PLpgSQL_execstate *estate, PLpgSQL_stmt_close *stmt)
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
{
PLpgSQL_var *curvar = NULL;
Portal portal;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
char *curname;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
/* ----------
* Get the portal of the cursor by name
* ----------
*/
curvar = (PLpgSQL_var *) (estate->datums[stmt->curvar]);
if (curvar->isnull)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("cursor variable \"%s\" is NULL", curvar->refname)));
Simplify and standardize conversions between TEXT datums and ordinary C strings. This patch introduces four support functions cstring_to_text, cstring_to_text_with_len, text_to_cstring, and text_to_cstring_buffer, and two macros CStringGetTextDatum and TextDatumGetCString. A number of existing macros that provided variants on these themes were removed. Most of the places that need to make such conversions now require just one function or macro call, in place of the multiple notational layers that used to be needed. There are no longer any direct calls of textout or textin, and we got most of the places that were using handmade conversions via memcpy (there may be a few still lurking, though). This commit doesn't make any serious effort to eliminate transient memory leaks caused by detoasting toasted text objects before they reach text_to_cstring. We changed PG_GETARG_TEXT_P to PG_GETARG_TEXT_PP in a few places where it was easy, but much more could be done. Brendan Jurd and Tom Lane
2008-03-25 23:42:46 +01:00
curname = TextDatumGetCString(curvar->value);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
portal = SPI_cursor_find(curname);
if (portal == NULL)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_CURSOR),
errmsg("cursor \"%s\" does not exist", curname)));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pfree(curname);
/* ----------
* And close it.
* ----------
*/
SPI_cursor_close(portal);
Added EXECUTE command to PL/pgSQL for execution of dynamic SQL and utility statements. Jan
2000-08-31 15:26:16 +02:00
return PLPGSQL_RC_OK;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
This patch improves the behavior of FOUND in PL/PgSQL. In Oracle, FOUND is set whenever a SELECT INTO returns > 0 rows, *or* when an INSERT, UPDATE, or DELETE affects > 0 rows. We implemented the first part of this behavior, but not the second. I also improved the documentation on the various situations in which FOUND can be set (excluding inside FOR loops, which I still need to think about), and added some regression tests for this behavior. Neil Conway
2002-08-20 07:28:24 +02:00
* exec_assign_expr Put an expression's result into
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* a variable.
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_assign_expr(PLpgSQL_execstate *estate, PLpgSQL_datum *target,
PLpgSQL_expr *expr)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum value;
Oid valtype;
bool isnull = false;
value = exec_eval_expr(estate, expr, &isnull, &valtype);
Cause plpgsql's PERFORM to behave according to its documentation, which says that PERFORM will execute any SELECT query and discard the result. The former implementation would in fact raise an error if the result contained more than one row or more than one column. Also, change plpgsql's error-logging mechanism to emit the additional messages about error location at NOTICE rather than DEBUG level. This allows them to be seen by the client without having to dig into the postmaster log file (which may be nonexistent or inaccessible by the client).
2001-05-28 21:33:24 +02:00
exec_assign_value(estate, target, value, valtype, &isnull);
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
exec_eval_cleanup(estate);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_assign_value Put a value into a target field
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_assign_value(PLpgSQL_execstate *estate,
PLpgSQL_datum *target,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum value, Oid valtype, bool *isNull)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
switch (target->dtype)
{
case PLPGSQL_DTYPE_VAR:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
/*
* Target is a variable
*/
PLpgSQL_var *var = (PLpgSQL_var *) target;
Datum newvalue;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
newvalue = exec_cast_value(value, valtype, var->datatype->typoid,
&(var->datatype->typinput),
var->datatype->typioparam,
var->datatype->atttypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
*isNull);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (*isNull && var->notnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("NULL cannot be assigned to variable \"%s\" declared NOT NULL",
var->refname)));
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* If type is by-reference, make sure we have a freshly
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* palloc'd copy; the originally passed value may not live as
* long as the variable! But we don't need to re-copy if
* exec_cast_value performed a conversion; its output must
* already be palloc'd.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
if (!var->datatype->typbyval && !*isNull)
{
if (newvalue == value)
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
newvalue = datumCopy(newvalue,
false,
var->datatype->typlen);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now free the old value. (We can't do this any earlier
* because of the possibility that we are assigning the var's
* old value to it, eg "foo := foo". We could optimize out
* the assignment altogether in such cases, but it's too
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
* infrequent to be worth testing for.)
*/
free_var(var);
var->value = newvalue;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
var->isnull = *isNull;
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
if (!var->datatype->typbyval && !*isNull)
var->freeval = true;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
break;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Support assignment to whole-row variables in plpgsql; also fix glitch with using a trigger's NEW or OLD record as a whole-row variable in an expression. Fixes several long-standing complaints.
2004-06-04 04:37:06 +02:00
case PLPGSQL_DTYPE_ROW:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Target is a row variable
*/
PLpgSQL_row *row = (PLpgSQL_row *) target;
/* Source must be of RECORD or composite type */
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
if (!type_is_rowtype(valtype))
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot assign non-composite value to a row variable")));
if (*isNull)
{
/* If source is null, just assign nulls to the row */
exec_move_row(estate, NULL, row, NULL, NULL);
}
else
{
HeapTupleHeader td;
Oid tupType;
int32 tupTypmod;
TupleDesc tupdesc;
HeapTupleData tmptup;
/* Else source is a tuple Datum, safe to do this: */
td = DatumGetHeapTupleHeader(value);
/* Extract rowtype info and find a tupdesc */
tupType = HeapTupleHeaderGetTypeId(td);
tupTypmod = HeapTupleHeaderGetTypMod(td);
tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
/* Build a temporary HeapTuple control structure */
tmptup.t_len = HeapTupleHeaderGetDatumLength(td);
ItemPointerSetInvalid(&(tmptup.t_self));
tmptup.t_tableOid = InvalidOid;
tmptup.t_data = td;
exec_move_row(estate, NULL, row, &tmptup, tupdesc);
Fix problems with cached tuple descriptors disappearing while still in use by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
2006-06-16 20:42:24 +02:00
ReleaseTupleDesc(tupdesc);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
break;
Support assignment to whole-row variables in plpgsql; also fix glitch with using a trigger's NEW or OLD record as a whole-row variable in an expression. Fixes several long-standing complaints.
2004-06-04 04:37:06 +02:00
}
case PLPGSQL_DTYPE_REC:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Target is a record variable
*/
PLpgSQL_rec *rec = (PLpgSQL_rec *) target;
/* Source must be of RECORD or composite type */
Support enum data types. Along the way, use macros for the values of pg_type.typtype whereever practical. Tom Dunstan, with some kibitzing from Tom Lane.
2007-04-02 05:49:42 +02:00
if (!type_is_rowtype(valtype))
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot assign non-composite value to a record variable")));
if (*isNull)
{
/* If source is null, just assign nulls to the record */
exec_move_row(estate, rec, NULL, NULL, NULL);
}
else
{
HeapTupleHeader td;
Oid tupType;
int32 tupTypmod;
TupleDesc tupdesc;
HeapTupleData tmptup;
/* Else source is a tuple Datum, safe to do this: */
td = DatumGetHeapTupleHeader(value);
/* Extract rowtype info and find a tupdesc */
tupType = HeapTupleHeaderGetTypeId(td);
tupTypmod = HeapTupleHeaderGetTypMod(td);
tupdesc = lookup_rowtype_tupdesc(tupType, tupTypmod);
/* Build a temporary HeapTuple control structure */
tmptup.t_len = HeapTupleHeaderGetDatumLength(td);
ItemPointerSetInvalid(&(tmptup.t_self));
tmptup.t_tableOid = InvalidOid;
tmptup.t_data = td;
exec_move_row(estate, rec, NULL, &tmptup, tupdesc);
Fix problems with cached tuple descriptors disappearing while still in use by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
2006-06-16 20:42:24 +02:00
ReleaseTupleDesc(tupdesc);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
break;
Support assignment to whole-row variables in plpgsql; also fix glitch with using a trigger's NEW or OLD record as a whole-row variable in an expression. Fixes several long-standing complaints.
2004-06-04 04:37:06 +02:00
}
case PLPGSQL_DTYPE_RECFIELD:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
/*
* Target is a field of a record
*/
PLpgSQL_recfield *recfield = (PLpgSQL_recfield *) target;
PLpgSQL_rec *rec;
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
int fno;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
HeapTuple newtup;
int natts;
Datum *values;
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
bool *nulls;
bool *replaces;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
void *mustfree;
bool attisnull;
Oid atttype;
int32 atttypmod;
rec = (PLpgSQL_rec *) (estate->datums[recfield->recparentno]);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Check that there is already a tuple in the record. We need
* that because records don't have any predefined field
* structure.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
if (!HeapTupleIsValid(rec->tup))
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Get the number of the records field to change and the
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
* number of attributes in the tuple. Note: disallow
* system column names because the code below won't cope.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
fno = SPI_fnumber(rec->tupdesc, recfield->fieldname);
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
if (fno <= 0)
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ereport(ERROR,
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("record \"%s\" has no field \"%s\"",
rec->refname, recfield->fieldname)));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
fno--;
natts = rec->tupdesc->natts;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
* Set up values/control arrays for heap_modify_tuple. For all
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* the attributes except the one we want to replace, use the
* value that's in the old tuple.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
values = palloc(sizeof(Datum) * natts);
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
nulls = palloc(sizeof(bool) * natts);
replaces = palloc(sizeof(bool) * natts);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
memset(replaces, false, sizeof(bool) * natts);
replaces[fno] = true;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Now insert the new value, being careful to cast it to the
* right type.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
atttype = SPI_gettypeid(rec->tupdesc, fno + 1);
atttypmod = rec->tupdesc->attrs[fno]->atttypmod;
attisnull = *isNull;
values[fno] = exec_simple_cast_value(value,
valtype,
atttype,
atttypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
attisnull);
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
nulls[fno] = attisnull;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Avoid leaking the result of exec_simple_cast_value, if it
* performed a conversion to a pass-by-ref type.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
if (!attisnull && values[fno] != value && !get_typbyval(atttype))
mustfree = DatumGetPointer(values[fno]);
else
mustfree = NULL;
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
* Now call heap_modify_tuple() to create a new tuple that
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
* replaces the old one in the record.
*/
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
newtup = heap_modify_tuple(rec->tup, rec->tupdesc,
values, nulls, replaces);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (rec->freetup)
heap_freetuple(rec->tup);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
rec->tup = newtup;
rec->freetup = true;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
pfree(values);
pfree(nulls);
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
pfree(replaces);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (mustfree)
pfree(mustfree);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
break;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
case PLPGSQL_DTYPE_ARRAYELEM:
pgindent run.
2003-08-04 02:43:34 +02:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
int nsubscripts;
int i;
PLpgSQL_expr *subscripts[MAXDIM];
int subscriptvals[MAXDIM];
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
bool oldarrayisnull;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Oid arraytypeid,
arrayelemtypeid;
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
int16 arraytyplen,
elemtyplen;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
bool elemtypbyval;
char elemtypalign;
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
Datum oldarraydatum,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
coerced_value;
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
ArrayType *oldarrayval;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ArrayType *newarrayval;
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Target is an element of an array
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* To handle constructs like x[1][2] := something, we have to
* be prepared to deal with a chain of arrayelem datums. Chase
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* back to find the base array datum, and save the subscript
* expressions as we go. (We are scanning right to left here,
* but want to evaluate the subscripts left-to-right to
* minimize surprises.)
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
nsubscripts = 0;
do
{
PLpgSQL_arrayelem *arrayelem = (PLpgSQL_arrayelem *) target;
if (nsubscripts >= MAXDIM)
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("number of array dimensions exceeds the maximum allowed, %d",
MAXDIM)));
subscripts[nsubscripts++] = arrayelem->subscript;
target = estate->datums[arrayelem->arrayparentno];
} while (target->dtype == PLPGSQL_DTYPE_ARRAYELEM);
/* Fetch current value of array datum */
exec_eval_datum(estate, target, InvalidOid,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
&arraytypeid, &oldarraydatum, &oldarrayisnull);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
arrayelemtypeid = get_element_type(arraytypeid);
if (!OidIsValid(arrayelemtypeid))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("subscripted object is not an array")));
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
get_typlenbyvalalign(arrayelemtypeid,
&elemtyplen,
&elemtypbyval,
&elemtypalign);
arraytyplen = get_typlen(arraytypeid);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
* Evaluate the subscripts, switch into left-to-right order.
* Like ExecEvalArrayRef(), complain if any subscript is null.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
for (i = 0; i < nsubscripts; i++)
{
bool subisnull;
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
subscriptvals[i] =
exec_eval_integer(estate,
subscripts[nsubscripts - 1 - i],
&subisnull);
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
if (subisnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("array subscript in assignment must not be NULL")));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
}
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
/* Coerce source value to match array element type. */
coerced_value = exec_simple_cast_value(value,
valtype,
arrayelemtypeid,
-1,
*isNull);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If the original array is null, cons up an empty array so
* that the assignment can proceed; we'll end with a
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
* one-element array containing just the assigned-to
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* subscript. This only works for varlena arrays, though; for
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
* fixed-length array types we skip the assignment. We can't
* support assignment of a null entry into a fixed-length
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* array, either, so that's a no-op too. This is all ugly but
* corresponds to the current behavior of ExecEvalArrayRef().
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
*/
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
if (arraytyplen > 0 && /* fixed-length array? */
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
(oldarrayisnull || *isNull))
return;
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
if (oldarrayisnull)
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
oldarrayval = construct_empty_array(arrayelemtypeid);
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
else
oldarrayval = (ArrayType *) DatumGetPointer(oldarraydatum);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Build the modified array value.
*/
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
newarrayval = array_set(oldarrayval,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
nsubscripts,
subscriptvals,
coerced_value,
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
*isNull,
Adjust plpgsql to allow assignment to an element of an array that is initially NULL. For 8.0 we changed the main executor to have this behavior in an UPDATE of an array column, but plpgsql's equivalent case was overlooked. Per report from Sven Willenberger.
2005-02-01 20:35:14 +01:00
arraytyplen,
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
elemtyplen,
elemtypbyval,
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
elemtypalign);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Avoid leaking the result of exec_simple_cast_value, if it
* performed a conversion to a pass-by-ref type.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
if (!*isNull && coerced_value != value && !elemtypbyval)
pfree(DatumGetPointer(coerced_value));
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
/*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* Assign the new array to the base variable. It's never NULL
* at this point.
Make SQL arrays support null elements. This commit fixes the core array functionality, but I still need to make another pass looking at places that incidentally use arrays (such as ACL manipulation) to make sure they are null-safe. Contrib needs work too. I have not changed the behaviors that are still under discussion about array comparison and what to do with lower bounds.
2005-11-17 23:14:56 +01:00
*/
*isNull = false;
exec_assign_value(estate, target,
PointerGetDatum(newarrayval),
arraytypeid, isNull);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
/*
* Avoid leaking the modified array value, too.
*/
pfree(newarrayval);
break;
}
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized dtype: %d", target->dtype);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
/*
* exec_eval_datum Get current value of a PLpgSQL_datum
*
* The type oid, value in Datum format, and null flag are returned.
*
* If expectedtypeid isn't InvalidOid, it is checked against the actual type.
*
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
* At present this doesn't handle PLpgSQL_expr or PLpgSQL_arrayelem datums.
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
*
* NOTE: caller must not modify the returned value, since it points right
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* at the stored value in the case of pass-by-reference datatypes. In some
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
* cases we have to palloc a return value, and in such cases we put it into
* the estate's short-term memory context.
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
*/
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_datum(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum,
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
Oid expectedtypeid,
Oid *typeid,
Datum *value,
bool *isnull)
{
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
MemoryContext oldcontext;
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
switch (datum->dtype)
{
case PLPGSQL_DTYPE_VAR:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
PLpgSQL_var *var = (PLpgSQL_var *) datum;
Allow plpgsql to pass composite-type arguments (ie, whole-row variables) into SQL expressions. At present this only works usefully for variables of named rowtypes, not RECORD variables, since the SQL parser can't infer anything about datatypes from a RECORD Param. Still, it's a step forward.
2004-06-04 02:07:52 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*typeid = var->datatype->typoid;
*value = var->value;
*isnull = var->isnull;
if (expectedtypeid != InvalidOid && expectedtypeid != *typeid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("type of \"%s\" does not match that when preparing the plan",
var->refname)));
break;
}
Allow plpgsql to pass composite-type arguments (ie, whole-row variables) into SQL expressions. At present this only works usefully for variables of named rowtypes, not RECORD variables, since the SQL parser can't infer anything about datatypes from a RECORD Param. Still, it's a step forward.
2004-06-04 02:07:52 +02:00
case PLPGSQL_DTYPE_ROW:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
PLpgSQL_row *row = (PLpgSQL_row *) datum;
HeapTuple tup;
if (!row->rowtupdesc) /* should not happen */
elog(ERROR, "row variable has no tupdesc");
/* Make sure we have a valid type/typmod setting */
BlessTupleDesc(row->rowtupdesc);
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
oldcontext = MemoryContextSwitchTo(estate->eval_econtext->ecxt_per_tuple_memory);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
tup = make_tuple_from_row(estate, row, row->rowtupdesc);
if (tup == NULL) /* should not happen */
elog(ERROR, "row not compatible with its own tupdesc");
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
MemoryContextSwitchTo(oldcontext);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*typeid = row->rowtupdesc->tdtypeid;
*value = HeapTupleGetDatum(tup);
*isnull = false;
if (expectedtypeid != InvalidOid && expectedtypeid != *typeid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("type of \"%s\" does not match that when preparing the plan",
row->refname)));
break;
}
Allow plpgsql to pass composite-type arguments (ie, whole-row variables) into SQL expressions. At present this only works usefully for variables of named rowtypes, not RECORD variables, since the SQL parser can't infer anything about datatypes from a RECORD Param. Still, it's a step forward.
2004-06-04 02:07:52 +02:00
case PLPGSQL_DTYPE_REC:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
PLpgSQL_rec *rec = (PLpgSQL_rec *) datum;
HeapTupleData worktup;
Allow plpgsql to pass composite-type arguments (ie, whole-row variables) into SQL expressions. At present this only works usefully for variables of named rowtypes, not RECORD variables, since the SQL parser can't infer anything about datatypes from a RECORD Param. Still, it's a step forward.
2004-06-04 02:07:52 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (!HeapTupleIsValid(rec->tup))
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Assert(rec->tupdesc != NULL);
/* Make sure we have a valid type/typmod setting */
BlessTupleDesc(rec->tupdesc);
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* In a trigger, the NEW and OLD parameters are likely to be
* on-disk tuples that don't have the desired Datum fields.
* Copy the tuple body and insert the right values.
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*/
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
oldcontext = MemoryContextSwitchTo(estate->eval_econtext->ecxt_per_tuple_memory);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
heap_copytuple_with_tuple(rec->tup, &worktup);
HeapTupleHeaderSetDatumLength(worktup.t_data, worktup.t_len);
HeapTupleHeaderSetTypeId(worktup.t_data, rec->tupdesc->tdtypeid);
HeapTupleHeaderSetTypMod(worktup.t_data, rec->tupdesc->tdtypmod);
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
MemoryContextSwitchTo(oldcontext);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*typeid = rec->tupdesc->tdtypeid;
*value = HeapTupleGetDatum(&worktup);
*isnull = false;
if (expectedtypeid != InvalidOid && expectedtypeid != *typeid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("type of \"%s\" does not match that when preparing the plan",
rec->refname)));
break;
}
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
case PLPGSQL_DTYPE_RECFIELD:
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
{
PLpgSQL_recfield *recfield = (PLpgSQL_recfield *) datum;
PLpgSQL_rec *rec;
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
int fno;
Allow plpgsql to pass composite-type arguments (ie, whole-row variables) into SQL expressions. At present this only works usefully for variables of named rowtypes, not RECORD variables, since the SQL parser can't infer anything about datatypes from a RECORD Param. Still, it's a step forward.
2004-06-04 02:07:52 +02:00
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
rec = (PLpgSQL_rec *) (estate->datums[recfield->recparentno]);
if (!HeapTupleIsValid(rec->tup))
ereport(ERROR,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
fno = SPI_fnumber(rec->tupdesc, recfield->fieldname);
if (fno == SPI_ERROR_NOATTRIBUTE)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_COLUMN),
errmsg("record \"%s\" has no field \"%s\"",
rec->refname, recfield->fieldname)));
*typeid = SPI_gettypeid(rec->tupdesc, fno);
*value = SPI_getbinval(rec->tup, rec->tupdesc, fno, isnull);
if (expectedtypeid != InvalidOid && expectedtypeid != *typeid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("type of \"%s.%s\" does not match that when preparing the plan",
rec->refname, recfield->fieldname)));
break;
}
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
case PLPGSQL_DTYPE_TRIGARG:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
PLpgSQL_trigarg *trigarg = (PLpgSQL_trigarg *) datum;
int tgargno;
*typeid = TEXTOID;
tgargno = exec_eval_integer(estate, trigarg->argnum, isnull);
if (*isnull || tgargno < 0 || tgargno >= estate->trig_nargs)
{
*value = (Datum) 0;
*isnull = true;
}
else
{
*value = estate->trig_argv[tgargno];
*isnull = false;
}
if (expectedtypeid != InvalidOid && expectedtypeid != *typeid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("type of tgargv[%d] does not match that when preparing the plan",
tgargno)));
break;
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
}
default:
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unrecognized dtype: %d", datum->dtype);
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
}
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
/* ----------
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
* exec_eval_integer Evaluate an expression, coerce result to int4
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
*
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
* Note we do not do exec_eval_cleanup here; the caller must do it at
* some later point. (We do this because the caller may be holding the
* results of other, pass-by-reference, expression evaluations, such as
* an array value to be subscripted. Also see notes in exec_eval_simple_expr
* about allocation of the parameter array.)
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
* ----------
*/
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_integer(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
bool *isNull)
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
{
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
Datum exprdatum;
Oid exprtypeid;
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
exprdatum = exec_eval_expr(estate, expr, isNull, &exprtypeid);
exprdatum = exec_simple_cast_value(exprdatum, exprtypeid,
INT4OID, -1,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
*isNull);
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
return DatumGetInt32(exprdatum);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
}
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
/* ----------
* exec_eval_boolean Evaluate an expression, coerce result to bool
*
* Note we do not do exec_eval_cleanup here; the caller must do it at
* some later point.
* ----------
*/
static bool
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_boolean(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
bool *isNull)
{
Datum exprdatum;
Oid exprtypeid;
exprdatum = exec_eval_expr(estate, expr, isNull, &exprtypeid);
exprdatum = exec_simple_cast_value(exprdatum, exprtypeid,
BOOLOID, -1,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
*isNull);
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
return DatumGetBool(exprdatum);
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_eval_expr Evaluate an expression and return
* the result Datum.
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
*
* NOTE: caller must do exec_eval_cleanup when done with the Datum.
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static Datum
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_expr(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
bool *isNull,
Oid *rettype)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Suppress a possibly-uninitialized-variable warning. (I'm only seeing it on Apple's gcc and not my other machines, but still it seems worth getting rid of.)
2008-05-16 20:34:51 +02:00
Datum result = 0;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
int rc;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
* If first time through, create a plan for this expression.
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
if (expr->plan == NULL)
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
exec_prepare_plan(estate, expr, 0);
Revert patch, needs more work: --------------------------------------------------------------------------- Add dynamic record inspection to PL/PgSQL, useful for generic triggers: tval2 := r.(cname); or columns := r.(*); Titus von Boxberg
2006-05-30 15:40:56 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
* If this is a simple expression, bypass SPI and use the executor
* directly
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
if (exec_eval_simple_expr(estate, expr, &result, isNull, rettype))
return result;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
/*
* Else do it the hard way via exec_run_select
*/
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
rc = exec_run_select(estate, expr, 2, NULL);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (rc != SPI_OK_SELECT)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("query \"%s\" did not return data", expr->query)));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* If there are no rows selected, the result is NULL.
*/
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_processed == 0)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
*isNull = true;
return (Datum) 0;
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* Check that the expression returned one single Datum
*/
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_processed > 1)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_CARDINALITY_VIOLATION),
errmsg("query \"%s\" returned more than one row",
expr->query)));
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
if (estate->eval_tuptable->tupdesc->natts != 1)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("query \"%s\" returned %d columns", expr->query,
estate->eval_tuptable->tupdesc->natts)));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Fix it's and its to be correct.
2000-01-05 19:23:54 +01:00
* Return the result and its type
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
*rettype = SPI_gettypeid(estate->eval_tuptable->tupdesc, 1);
return SPI_getbinval(estate->eval_tuptable->vals[0],
estate->eval_tuptable->tupdesc, 1, isNull);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
/* ----------
* exec_run_select Execute a select query
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static int
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_run_select(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, long maxtuples, Portal *portalP)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Datum *values;
char *nulls;
int rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
* On the first call for this expression generate the plan
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (expr->plan == NULL)
Support scrollable cursors (ie, 'direction' clause in FETCH) in plpgsql. Pavel Stehule, reworked a bit by Tom.
2007-04-16 19:21:24 +02:00
exec_prepare_plan(estate, expr, 0);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
* Now build up the values and nulls arguments for SPI_execute_plan()
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
*/
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
eval_expr_params(estate, expr, &values, &nulls);
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
* If a portal was requested, put the query into the portal
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (portalP != NULL)
{
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
*portalP = SPI_cursor_open(NULL, expr->plan, values, nulls,
estate->readonly_func);
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (*portalP == NULL)
Be more consistent about reporting SPI errors in the various PLs. Create a shared function to convert a SPI error code into a string (replacing near-duplicate code in several PLs), and use it anywhere that a SPI function call error is reported.
2004-07-31 22:55:45 +02:00
elog(ERROR, "could not open implicit cursor for query \"%s\": %s",
expr->query, SPI_result_code_string(SPI_result));
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
pfree(values);
pfree(nulls);
return SPI_OK_CURSOR;
}
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/*
* Execute the query
*/
Redesign query-snapshot timing so that volatile functions in READ COMMITTED mode see a fresh snapshot for each command in the function, rather than using the latest interactive command's snapshot. Also, suppress fresh snapshots as well as CommandCounterIncrement inside STABLE and IMMUTABLE functions, instead using the snapshot taken for the most closely nested regular query. (This behavior is only sane for read-only functions, so the patch also enforces that such functions contain only SELECT commands.) As per my proposal of 6-Sep-2004; I note that I floated essentially the same proposal on 19-Jun-2002, but that discussion tailed off without any action. Since 8.0 seems like the right place to be taking possibly nontrivial backwards compatibility hits, let's get it done now.
2004-09-13 22:10:13 +02:00
rc = SPI_execute_plan(expr->plan, values, nulls,
estate->readonly_func, maxtuples);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (rc != SPI_OK_SELECT)
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("query \"%s\" is not a SELECT", expr->query)));
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/* Save query results for eventual cleanup */
Assert(estate->eval_tuptable == NULL);
estate->eval_tuptable = SPI_tuptable;
estate->eval_processed = SPI_processed;
estate->eval_lastoid = SPI_lastoid;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
pfree(values);
pfree(nulls);
return rc;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* exec_for_query --- execute body of FOR loop for each row from a portal
*
* Used by exec_stmt_fors, exec_stmt_forc and exec_stmt_dynfors
*/
static int
exec_for_query(PLpgSQL_execstate *estate, PLpgSQL_stmt_forq *stmt,
Portal portal, bool prefetch_ok)
{
PLpgSQL_rec *rec = NULL;
PLpgSQL_row *row = NULL;
SPITupleTable *tuptab;
bool found = false;
int rc = PLPGSQL_RC_OK;
int n;
/*
* Determine if we assign to a record or a row
*/
if (stmt->rec != NULL)
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->recno]);
else if (stmt->row != NULL)
row = (PLpgSQL_row *) (estate->datums[stmt->row->rowno]);
else
elog(ERROR, "unsupported target");
/*
* Fetch the initial tuple(s). If prefetching is allowed then we grab
* a few more rows to avoid multiple trips through executor startup
* overhead.
*/
SPI_cursor_fetch(portal, true, prefetch_ok ? 10 : 1);
tuptab = SPI_tuptable;
n = SPI_processed;
/*
* If the query didn't return any rows, set the target to NULL and
* fall through with found = false.
*/
if (n <= 0)
exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);
else
found = true; /* processed at least one tuple */
/*
* Now do the loop
*/
while (n > 0)
{
int i;
for (i = 0; i < n; i++)
{
/*
* Assign the tuple to the target
*/
exec_move_row(estate, rec, row, tuptab->vals[i], tuptab->tupdesc);
/*
* Execute the statements
*/
rc = exec_stmts(estate, stmt->body);
if (rc != PLPGSQL_RC_OK)
{
if (rc == PLPGSQL_RC_EXIT)
{
if (estate->exitlabel == NULL)
{
/* unlabelled exit, so exit the current loop */
rc = PLPGSQL_RC_OK;
}
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
{
/* label matches this loop, so exit loop */
estate->exitlabel = NULL;
rc = PLPGSQL_RC_OK;
}
/*
* otherwise, we processed a labelled exit that does not
* match the current statement's label, if any; return
* RC_EXIT so that the EXIT continues to recurse upward.
*/
}
else if (rc == PLPGSQL_RC_CONTINUE)
{
if (estate->exitlabel == NULL)
{
/* unlabelled continue, so re-run the current loop */
rc = PLPGSQL_RC_OK;
continue;
}
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
{
/* label matches this loop, so re-run loop */
estate->exitlabel = NULL;
rc = PLPGSQL_RC_OK;
continue;
}
/*
* otherwise, we process a labelled continue that does not
* match the current statement's label, if any; return
* RC_CONTINUE so that the CONTINUE will propagate up the
* stack.
*/
}
/*
* We're aborting the loop. Need a goto to get out of two
* levels of loop...
*/
goto loop_exit;
}
}
SPI_freetuptable(tuptab);
/*
* Fetch more tuples. If prefetching is allowed, grab 50 at a time.
*/
SPI_cursor_fetch(portal, true, prefetch_ok ? 50 : 1);
tuptab = SPI_tuptable;
n = SPI_processed;
}
loop_exit:
/*
* Release last group of tuples (if any)
*/
SPI_freetuptable(tuptab);
/*
* Set the FOUND variable to indicate the result of executing the loop
* (namely, whether we looped one or more times). This must be set last so
* that it does not interfere with the value of the FOUND variable inside
* the loop processing itself.
*/
exec_set_found(estate, found);
return rc;
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
/* ----------
* exec_eval_simple_expr - Evaluate a simple expression returning
* a Datum by directly calling ExecEvalExpr().
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
* If successful, store results into *result, *isNull, *rettype and return
* TRUE. If the expression is not simple (any more), return FALSE.
*
* It is possible though unlikely for a simple expression to become non-simple
* (consider for example redefining a trivial view). We must handle that for
* correctness; fortunately it's normally inexpensive to do
* RevalidateCachedPlan on a simple expression. We do not consider the other
* direction (non-simple expression becoming simple) because we'll still give
* correct results if that happens, and it's unlikely to be worth the cycles
* to check.
*
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
* Note: if pass-by-reference, the result is in the eval_econtext's
* temporary memory context. It will be freed when exec_eval_cleanup
* is done.
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
* ----------
*/
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
static bool
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_eval_simple_expr(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr,
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
Datum *result,
pgindent run over code.
1999-05-25 18:15:34 +02:00
bool *isNull,
Oid *rettype)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
{
exec_eval_datum leaks memory when dealing with ROW or REC values. It never leaked memory before PG 8.0, so none of the callers are expecting this. Cleanest fix seems to be to make it allocate the needed memory in estate->eval_econtext, where it will be cleaned up by the next exec_eval_cleanup. Per report from Bill Rugolsky.
2005-06-21 00:51:29 +02:00
ExprContext *econtext = estate->eval_econtext;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
CachedPlanSource *plansource;
CachedPlan *cplan;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
ParamListInfo paramLI;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
int i;
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
MemoryContext oldcontext;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
/*
* Forget it if expression wasn't simple before.
*/
if (expr->expr_simple_expr == NULL)
return false;
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Revalidate cached plan, so that we will notice if it became stale. (We
* also need to hold a refcount while using the plan.) Note that even if
* replanning occurs, the length of plancache_list can't change, since it
* is a property of the raw parsetree generated from the query text.
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
*/
Assert(list_length(expr->plan->plancache_list) == 1);
plansource = (CachedPlanSource *) linitial(expr->plan->plancache_list);
cplan = RevalidateCachedPlan(plansource, true);
if (cplan->generation != expr->expr_simple_generation)
{
/* It got replanned ... is it still simple? */
exec_simple_check_plan(expr);
if (expr->expr_simple_expr == NULL)
{
/* Ooops, release refcount and fail */
ReleaseCachedPlan(cplan, true);
return false;
}
}
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
/*
* Pass back previously-determined result type.
*/
*rettype = expr->expr_simple_type;
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Prepare the expression for execution, if it's not been done already in
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
* the current eval_estate. (This will be forced to happen if we called
* exec_simple_check_plan above.)
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*/
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
if (expr->expr_simple_id != estate->eval_estate_simple_id)
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
{
expr->expr_simple_state = ExecPrepareExpr(expr->expr_simple_expr,
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
estate->eval_estate);
expr->expr_simple_id = estate->eval_estate_simple_id;
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
/*
* Param list can live in econtext's temporary memory context.
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* XXX think about avoiding repeated palloc's for param lists? Beware
* however that this routine is re-entrant: exec_eval_datum() can call it
* back for subscript evaluation, and so there can be a need to have more
* than one active param list.
Clean up various memory leaks within plpgsql, and re-enable the exec_eval_simple_expr shortcut, which was diked out in 7.1 because it leaked too much space. CVS tip now leaks no memory in Chris Ruprecht's example, which formerly leaked to the tune of 500 MB. (Much of this is work that Jan already did; this commit just cleans up around the edges.)
2001-08-02 23:31:23 +02:00
*/
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
if (expr->nparams > 0)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
{
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
/* sizeof(ParamListInfoData) includes the first array element */
paramLI = (ParamListInfo)
MemoryContextAlloc(econtext->ecxt_per_tuple_memory,
sizeof(ParamListInfoData) +
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
(expr->nparams - 1) *sizeof(ParamExternData));
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
paramLI->numParams = expr->nparams;
for (i = 0; i < expr->nparams; i++)
{
ParamExternData *prm = &paramLI->params[i];
PLpgSQL_datum *datum = estate->datums[expr->params[i]];
Factor out duplicate code for computing values of PLpgSQL_datum items. This is to help localize the changes needed for adding a new kind of PLpgSQL_datum (like, say, an array element...)
2003-03-25 01:34:24 +01:00
Change processing of extended-Query mode so that an unnamed statement that has parameters is always planned afresh for each Bind command, treating the parameter values as constants in the planner. This removes the performance penalty formerly often paid for using out-of-line parameters --- with this definition, the planner can do constant folding, LIKE optimization, etc. After a suggestion by Andrew@supernews.
2006-09-06 22:40:48 +02:00
prm->pflags = 0;
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
exec_eval_datum(estate, datum, expr->plan_argtypes[i],
&prm->ptype,
&prm->value, &prm->isnull);
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
Simplify ParamListInfo data structure to support only numbered parameters, not named ones, and replace linear searches of the list with array indexing. The named-parameter support has been dead code for many years anyway, and recent profiling suggests that the searching was costing a noticeable amount of performance for complex queries.
2006-04-22 03:26:01 +02:00
else
paramLI = NULL;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
* Now we can safely make the econtext point to the param list.
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
econtext->ecxt_param_list_info = paramLI;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We have to do some of the things SPI_execute_plan would do, in
* particular advance the snapshot if we are in a non-read-only function.
* Without this, stable functions within the expression would fail to see
* updates made so far by our own function.
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
SPI_push();
plpgsql's exec_eval_simple_expr() now has to take responsibility for advancing ActiveSnapshot when we are inside a volatile function. Per example from Gaetano Mendola. Add a regression test to catch similar problems in future.
2004-12-19 21:20:27 +01:00
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
oldcontext = MemoryContextSwitchTo(econtext->ecxt_per_tuple_memory);
if (!estate->readonly_func)
plpgsql's exec_eval_simple_expr() now has to take responsibility for advancing ActiveSnapshot when we are inside a volatile function. Per example from Gaetano Mendola. Add a regression test to catch similar problems in future.
2004-12-19 21:20:27 +01:00
{
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
CommandCounterIncrement();
PushActiveSnapshot(GetTransactionSnapshot());
}
plpgsql's exec_eval_simple_expr() now has to take responsibility for advancing ActiveSnapshot when we are inside a volatile function. Per example from Gaetano Mendola. Add a regression test to catch similar problems in future.
2004-12-19 21:20:27 +01:00
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
/*
* Finally we can call the executor to evaluate the expression
*/
*result = ExecEvalExpr(expr->expr_simple_state,
econtext,
isNull,
NULL);
MemoryContextSwitchTo(oldcontext);
exec_eval_simple_expr() needs to do CommandCounterIncrement() not just GetTransactionSnapshot() to ensure ActiveSnapshot advances properly. Sigh. Extend regression test so it reveals this error too.
2004-12-21 19:33:36 +01:00
Improve snapshot manager by keeping explicit track of snapshots. There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.
2008-05-12 22:02:02 +02:00
if (!estate->readonly_func)
PopActiveSnapshot();
plpgsql's exec_eval_simple_expr() now has to take responsibility for advancing ActiveSnapshot when we are inside a volatile function. Per example from Gaetano Mendola. Add a regression test to catch similar problems in future.
2004-12-19 21:20:27 +01:00
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
SPI_pop();
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
/*
* Now we can release our refcount on the cached plan.
*/
ReleaseCachedPlan(cplan, true);
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
* That's it.
*/
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
return true;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* Build up the values and nulls arguments for SPI_execute_plan()
*/
static void
eval_expr_params(PLpgSQL_execstate *estate,
PLpgSQL_expr *expr, Datum **p_values, char **p_nulls)
{
Datum *values;
char *nulls;
int i;
*p_values = values = (Datum *) palloc(expr->nparams * sizeof(Datum));
*p_nulls = nulls = (char *) palloc(expr->nparams * sizeof(char));
for (i = 0; i < expr->nparams; i++)
{
PLpgSQL_datum *datum = estate->datums[expr->params[i]];
Oid paramtypeid;
bool paramisnull;
exec_eval_datum(estate, datum, expr->plan_argtypes[i],
&paramtypeid, &values[i], &paramisnull);
if (paramisnull)
nulls[i] = 'n';
else
nulls[i] = ' ';
}
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
* exec_move_row Move one tuple's values into a record or row
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_move_row(PLpgSQL_execstate *estate,
PLpgSQL_rec *rec,
PLpgSQL_row *row,
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
HeapTuple tup, TupleDesc tupdesc)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTO that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
2003-01-21 23:06:12 +01:00
* Record is simple - just copy the tuple and its descriptor into the
* record variable
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (rec != NULL)
{
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
/*
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
* Copy input first, just in case it is pointing at variable's value
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
*/
if (HeapTupleIsValid(tup))
tup = heap_copytuple(tup);
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
else if (tupdesc)
{
/* If we have a tupdesc but no data, form an all-nulls tuple */
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
bool *nulls;
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
nulls = (bool *) palloc(tupdesc->natts * sizeof(bool));
memset(nulls, true, tupdesc->natts * sizeof(bool));
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
Remove all uses of the deprecated functions heap_formtuple, heap_modifytuple, and heap_deformtuple in favor of the newer functions heap_form_tuple et al (which do the same things but use bool control flags instead of arbitrary char values). Eliminate the former duplicate coding of these functions, reducing the deprecated functions to mere wrappers around the newer ones. We can't get rid of them entirely because add-on modules probably still contain many instances of the old coding style. Kris Jurka
2008-11-02 02:45:28 +01:00
tup = heap_form_tuple(tupdesc, NULL, nulls);
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
pfree(nulls);
}
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
if (tupdesc)
tupdesc = CreateTupleDescCopy(tupdesc);
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
/* Free the old value ... */
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
if (rec->freetup)
{
heap_freetuple(rec->tup);
rec->freetup = false;
}
if (rec->freetupdesc)
{
FreeTupleDesc(rec->tupdesc);
rec->freetupdesc = false;
}
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
/* ... and install the new */
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (HeapTupleIsValid(tup))
{
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
rec->tup = tup;
Enhancement of SPI to get access to portals - New functions to create a portal using a prepared/saved SPI plan or lookup an existing portal by name. - Functions to fetch/move from/in portals. Results are placed in the usual SPI_processed and SPI_tuptable, so the entire set of utility functions can be used to gain attribute access. - Prepared/saved SPI plans now use their own memory context and SPI_freeplan(plan) can remove them. - Tuple result sets (SPI_tuptable) now uses it's own memory context and can be free'd by SPI_freetuptable(tuptab). Enhancement of PL/pgSQL - Uses generic named portals internally in FOR ... SELECT loops to avoid running out of memory on huge result sets. - Support for CURSOR and REFCURSOR syntax using the new SPI functionality. Cursors used internally only need no explicit transaction block. Refcursor variables can be used inside of explicit transaction block to pass cursors between main application and functions. Jan
2001-05-21 16:22:19 +02:00
rec->freetup = true;
Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTO that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
2003-01-21 23:06:12 +01:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
rec->tup = NULL;
Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTO that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
2003-01-21 23:06:12 +01:00
if (tupdesc)
{
plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on "var := var" if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie.
2005-06-20 22:44:44 +02:00
rec->tupdesc = tupdesc;
Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTO that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
2003-01-21 23:06:12 +01:00
rec->freetupdesc = true;
}
else
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
rec->tupdesc = NULL;
return;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
* Row is a bit more complicated in that we assign the individual
* attributes of the tuple to the variables the row points to.
*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* NOTE: this code used to demand row->nfields ==
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
* HeapTupleHeaderGetNatts(tup->t_data), but that's wrong. The tuple might
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* have more fields than we expected if it's from an inheritance-child
* table of the current table, or it might have fewer if the table has had
* columns added by ALTER TABLE. Ignore extra columns and assume NULL for
* missing columns, the same as heap_getattr would do. We also have to
* skip over dropped columns in either the source or destination.
Fix coredump problem in plpgsql's RETURN NEXT. When a SELECT INTO that's selecting into a RECORD variable returns zero rows, make it assign an all-nulls row to the RECORD; this is consistent with what happens when the SELECT INTO target is not a RECORD. In support of this, tweak the SPI code so that a valid tuple descriptor is returned even when a SPI select returns no rows.
2003-01-21 23:06:12 +01:00
*
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
* If we have no tuple data at all, we'll assign NULL to all columns of
* the row variable.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
if (row != NULL)
{
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
int td_natts = tupdesc ? tupdesc->natts : 0;
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
int t_natts;
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
int fnum;
int anum;
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (HeapTupleIsValid(tup))
Enable another five tuple status bits by using the high bits of the nattr field, and rename the field. Heikki Linnakangas
2007-01-09 23:01:00 +01:00
t_natts = HeapTupleHeaderGetNatts(tup->t_data);
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
else
t_natts = 0;
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
anum = 0;
for (fnum = 0; fnum < row->nfields; fnum++)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
PLpgSQL_var *var;
Datum value;
bool isnull;
Oid valtype;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
if (row->varnos[fnum] < 0)
continue; /* skip dropped column in row struct */
var = (PLpgSQL_var *) (estate->datums[row->varnos[fnum]]);
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
while (anum < td_natts && tupdesc->attrs[anum]->attisdropped)
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
anum++; /* skip dropped column in tuple */
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
if (anum < td_natts)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this.
2008-09-02 00:30:33 +02:00
if (anum < t_natts)
value = SPI_getbinval(tup, tupdesc, anum + 1, &isnull);
else
{
value = (Datum) 0;
isnull = true;
}
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
valtype = SPI_gettypeid(tupdesc, anum + 1);
anum++;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
else
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
value = (Datum) 0;
isnull = true;
Un-break exec_move_row() for case that a NULL tuple and tupdesc are passed, which occurs when no rows are retrieved by a SELECT. Mea maxima culpa ... I should have caught this.
2001-05-08 03:00:53 +02:00
valtype = InvalidOid;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
exec_assign_value(estate, (PLpgSQL_datum *) var,
exec_move_row() should be more forgiving of tuples with a different number of columns than it was expecting, for reasons that are now documented in the code...
2001-04-30 22:05:40 +02:00
value, valtype, &isnull);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
return;
}
Error message editing in src/pl. The plpython module could use another look ... I'm not real certain which errors are strictly internal and which are likely to be provoked by users.
2003-07-26 01:37:31 +02:00
elog(ERROR, "unsupported target");
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
/* ----------
* make_tuple_from_row Make a tuple from the values of a row object
*
* A NULL return indicates rowtype mismatch; caller must raise suitable error
* ----------
*/
static HeapTuple
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
make_tuple_from_row(PLpgSQL_execstate *estate,
PLpgSQL_row *row,
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
TupleDesc tupdesc)
{
int natts = tupdesc->natts;
HeapTuple tuple;
Datum *dvalues;
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
bool *nulls;
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
int i;
if (natts != row->nfields)
return NULL;
dvalues = (Datum *) palloc0(natts * sizeof(Datum));
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
nulls = (bool *) palloc(natts * sizeof(bool));
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
for (i = 0; i < natts; i++)
{
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
Oid fieldtypeid;
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
if (tupdesc->attrs[i]->attisdropped)
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
{
nulls[i] = true; /* leave the column as null */
continue;
}
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
if (row->varnos[i] < 0) /* should not happen */
elog(ERROR, "dropped rowtype entry for non-dropped column");
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
exec_eval_datum(estate, estate->datums[row->varnos[i]],
InvalidOid, &fieldtypeid, &dvalues[i], &nulls[i]);
if (fieldtypeid != tupdesc->attrs[i]->atttypid)
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
return NULL;
}
Fix make_tuple_from_row to support nested rowtypes, per gripe from Roman Neuhauser. Update some obsolete comments for exec_eval_datum, too.
2005-09-13 18:16:17 +02:00
tuple = heap_form_tuple(tupdesc, dvalues, nulls);
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
pfree(dvalues);
pfree(nulls);
return tuple;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
/* ----------
* convert_value_to_string Convert a non-null Datum to C string
*
* Note: callers generally assume that the result is a palloc'd string and
* should be pfree'd. This is not all that safe an assumption ...
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
*
* Note: not caching the conversion function lookup is bad for performance.
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
* ----------
*/
static char *
convert_value_to_string(Datum value, Oid valtype)
{
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
char *str;
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid typoutput;
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
bool typIsVarlena;
Change CREATE TYPE to require datatype output and send functions to have only one argument. (Per recent discussion, the option to accept multiple arguments is pretty useless for user-defined types, and would be a likely source of security holes if it was used.) Simplify call sites of output/send functions to not bother passing more than one argument.
2005-05-01 20:56:19 +02:00
getTypeOutputInfo(valtype, &typoutput, &typIsVarlena);
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
/*
* We do SPI_push to allow the datatype output function to use SPI.
* However we do not mess around with CommandCounterIncrement or advancing
* the snapshot, which means that a stable output function would not see
* updates made so far by our own function. The use-case for such
* scenarios seems too narrow to justify the cycles that would be
* expended.
*/
SPI_push();
str = OidOutputFunctionCall(typoutput, value);
SPI_pop();
return str;
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_cast_value Cast a value if required
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static Datum
exec_cast_value(Datum value, Oid valtype,
Oid reqtype,
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
FmgrInfo *reqinput,
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid reqtypioparam,
Fix a passel of problems with incorrect calls to typinput and typoutput functions, which would lead to trouble with datatypes that paid attention to the typelem or typmod parameters to these functions. In particular, incorrect code in pg_aggregate.c explains the platform-specific failures that have been reported in NUMERIC avg().
2000-01-15 23:43:25 +01:00
int32 reqtypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
bool isnull)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
/*
* If the type of the queries return value isn't that of the variable,
* convert it.
*/
if (valtype != reqtype || reqtypmod != -1)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
if (!isnull)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
{
char *extval;
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
extval = convert_value_to_string(value, valtype);
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
/* Allow input function to use SPI ... see notes above */
SPI_push();
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
value = InputFunctionCall(reqinput, extval,
reqtypioparam, reqtypmod);
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
SPI_pop();
Fix a passel of problems with incorrect calls to typinput and typoutput functions, which would lead to trouble with datatypes that paid attention to the typelem or typmod parameters to these functions. In particular, incorrect code in pg_aggregate.c explains the platform-specific failures that have been reported in NUMERIC avg().
2000-01-15 23:43:25 +01:00
pfree(extval);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
}
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
else
{
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
SPI_push();
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
value = InputFunctionCall(reqinput, NULL,
reqtypioparam, reqtypmod);
Add SPI_push/SPI_pop calls so that datatype input and output functions called by plpgsql can themselves use SPI --- possibly indirectly, as in the case of domain_in() invoking plpgsql functions in a domain check constraint. Per bug #2945 from Sergiy Vyshnevetskiy. Somewhat arbitrarily, I've chosen to back-patch this as far as 8.0. Given the lack of prior complaints, it doesn't seem critical for 7.x.
2007-01-30 19:02:22 +01:00
SPI_pop();
Modify all callers of datatype input and receive functions so that if these functions are not strict, they will be called (passing a NULL first parameter) during any attempt to input a NULL value of their datatype. Currently, all our input functions are strict and so this commit does not change any behavior. However, this will make it possible to build domain input functions that centralize checking of domain constraints, thereby closing numerous holes in our domain support, as per previous discussion. While at it, I took the opportunity to introduce convenience functions InputFunctionCall, OutputFunctionCall, etc to use in code that calls I/O functions. This eliminates a lot of grotty-looking casts, but the main motivation is to make it easier to grep for these places if we ever need to touch them again.
2006-04-04 21:35:37 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
return value;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
}
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
/* ----------
* exec_simple_cast_value Cast a value if required
*
* As above, but need not supply details about target type. Note that this
* is slower than exec_cast_value with cached type info, and so should be
* avoided in heavily used code paths.
* ----------
*/
static Datum
exec_simple_cast_value(Datum value, Oid valtype,
Oid reqtype, int32 reqtypmod,
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
bool isnull)
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
{
Refactor exec_cast_value() and exec_simple_cast_value(): since they do not ever write through the `isnull' parameter, it does not need to be an out parameter. Therefore it can be declared a "bool" rather than a "bool *".
2005-07-28 09:51:13 +02:00
if (!isnull)
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
{
if (valtype != reqtype || reqtypmod != -1)
{
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
Oid typinput;
Oid typioparam;
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
FmgrInfo finfo_input;
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
getTypeInputInfo(reqtype, &typinput, &typioparam);
Add code to check that IF/WHILE/EXIT test expressions are boolean, and try to coerce the values to boolean if not. Per recent discussions.
2003-10-01 23:47:42 +02:00
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
fmgr_info(typinput, &finfo_input);
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
value = exec_cast_value(value,
valtype,
reqtype,
&finfo_input,
Infrastructure for I/O of composite types: arrange for the I/O routines of a composite type to get that type's OID as their second parameter, in place of typelem which is useless. The actual changes are mostly centralized in getTypeInputInfo and siblings, but I had to fix a few places that were fetching pg_type.typelem for themselves instead of using the lsyscache.c routines. Also, I renamed all the related variables from 'typelem' to 'typioparam' to discourage people from assuming that they necessarily contain array element types.
2004-06-06 02:41:28 +02:00
typioparam,
plpgsql can assign to subscripted variables now, e.g. x[42] := whatever; The facility is pretty primitive because it doesn't do array slicing and it has the same semantics as array update in SQL (array must already be non-null, etc). But it's a start.
2003-03-25 04:16:41 +01:00
reqtypmod,
isnull);
}
}
return value;
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
/* ----------
* exec_simple_check_node - Recursively check if an expression
* is made only of simple things we can
* hand out directly to ExecEvalExpr()
* instead of calling SPI.
* ----------
*/
static bool
pgindent run over code.
1999-05-25 18:15:34 +02:00
exec_simple_check_node(Node *node)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
{
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (node == NULL)
return TRUE;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
switch (nodeTag(node))
{
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_Const:
return TRUE;
case T_Param:
return TRUE;
case T_ArrayRef:
pgindent run over code.
1999-05-25 18:15:34 +02:00
{
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
ArrayRef *expr = (ArrayRef *) node;
pgindent run over code.
1999-05-25 18:15:34 +02:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (!exec_simple_check_node((Node *) expr->refupperindexpr))
return FALSE;
if (!exec_simple_check_node((Node *) expr->reflowerindexpr))
return FALSE;
if (!exec_simple_check_node((Node *) expr->refexpr))
return FALSE;
if (!exec_simple_check_node((Node *) expr->refassgnexpr))
return FALSE;
pgindent run over code.
1999-05-25 18:15:34 +02:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
return TRUE;
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_FuncExpr:
{
FuncExpr *expr = (FuncExpr *) node;
if (expr->funcretset)
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
pgindent run over code.
1999-05-25 18:15:34 +02:00
return TRUE;
}
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_OpExpr:
{
OpExpr *expr = (OpExpr *) node;
pgindent run over code.
1999-05-25 18:15:34 +02:00
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (expr->opretset)
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
case T_DistinctExpr:
{
DistinctExpr *expr = (DistinctExpr *) node;
if (expr->opretset)
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
Support expressions of the form 'scalar op ANY (array)' and 'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
2003-06-29 02:33:44 +02:00
case T_ScalarArrayOpExpr:
{
ScalarArrayOpExpr *expr = (ScalarArrayOpExpr *) node;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_BoolExpr:
{
BoolExpr *expr = (BoolExpr *) node;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
case T_FieldSelect:
return exec_simple_check_node((Node *) ((FieldSelect *) node)->arg);
pgindent run over code.
1999-05-25 18:15:34 +02:00
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
case T_FieldStore:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
FieldStore *expr = (FieldStore *) node;
Support assignment to subfields of composite columns in UPDATE and INSERT. As a side effect, cause subscripts in INSERT targetlists to do something more or less sensible; previously we evaluated such subscripts and then effectively ignored them. Another side effect is that UPDATE-ing an element or slice of an array value that is NULL now produces a non-null result, namely an array containing just the assigned-to positions.
2004-06-09 21:08:20 +02:00
if (!exec_simple_check_node((Node *) expr->arg))
return FALSE;
if (!exec_simple_check_node((Node *) expr->newvals))
return FALSE;
return TRUE;
}
Clean up handling of variable-free qual clauses. System now does the right thing with variable-free clauses that contain noncachable functions, such as 'WHERE random() < 0.5' --- these are evaluated once per potential output tuple. Expressions that contain only Params are now candidates to be indexscan quals --- for example, 'var = ($1 + 1)' can now be indexed. Cope with RelabelType nodes atop potential indexscan variables --- this oversight prevents 7.0.* from recognizing some potentially indexscanable situations.
2000-08-13 04:50:35 +02:00
case T_RelabelType:
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
return exec_simple_check_node((Node *) ((RelabelType *) node)->arg);
Downgrade implicit casts to text to be assignment-only, except for the ones from the other string-category types; this eliminates a lot of surprising interpretations that the parser could formerly make when there was no directly applicable operator. Create a general mechanism that supports casts to and from the standard string types (text,varchar,bpchar) for *every* datatype, by invoking the datatype's I/O functions. These new casts are assignment-only in the to-string direction, explicit-only in the other, and therefore should create no surprising behavior. Remove a bunch of thereby-obsoleted datatype-specific casting functions. The "general mechanism" is a new expression node type CoerceViaIO that can actually convert between *any* two datatypes if their external text representations are compatible. This is more general than needed for the immediate feature, but might be useful in plpgsql or other places in future. This commit does nothing about the issue that applying the concatenation operator || to non-text types will now fail, often with strange error messages due to misinterpreting the operator as array concatenation. Since it often (not always) worked before, we should either make it succeed or at least give a more user-friendly error; but details are still under debate. Peter Eisentraut and Tom Lane
2007-06-05 23:31:09 +02:00
case T_CoerceViaIO:
return exec_simple_check_node((Node *) ((CoerceViaIO *) node)->arg);
Fix array coercion expressions to ensure that the correct volatility is seen by code inspecting the expression. The best way to do this seems to be to drop the original representation as a function invocation, and instead make a special expression node type that represents applying the element-type coercion function to each array element. In this way the element function is exposed and will be checked for volatility. Per report from Guillaume Smet.
2007-03-28 01:21:12 +02:00
case T_ArrayCoerceExpr:
return exec_simple_check_node((Node *) ((ArrayCoerceExpr *) node)->arg);
Instead of supposing (wrongly, in the general case) that the rowtype of an inheritance child table is binary-compatible with the rowtype of its parent, invent an expression node type that does the conversion correctly. Fixes the new bug exhibited by Kris Shannon as well as a lot of old bugs that would only show up when using multiple inheritance or after altering the parent table.
2004-12-12 00:26:51 +01:00
case T_ConvertRowtypeExpr:
return exec_simple_check_node((Node *) ((ConvertRowtypeExpr *) node)->arg);
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_CaseExpr:
{
CaseExpr *expr = (CaseExpr *) node;
if (!exec_simple_check_node((Node *) expr->arg))
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
if (!exec_simple_check_node((Node *) expr->defresult))
return FALSE;
return TRUE;
}
case T_CaseWhen:
{
CaseWhen *when = (CaseWhen *) node;
if (!exec_simple_check_node((Node *) when->expr))
return FALSE;
if (!exec_simple_check_node((Node *) when->result))
return FALSE;
return TRUE;
}
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
case T_CaseTestExpr:
return TRUE;
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
case T_ArrayExpr:
{
pgindent run.
2003-08-04 02:43:34 +02:00
ArrayExpr *expr = (ArrayExpr *) node;
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
if (!exec_simple_check_node((Node *) expr->elements))
return FALSE;
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
return TRUE;
}
case T_RowExpr:
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
RowExpr *expr = (RowExpr *) node;
Promote row expressions to full-fledged citizens of the expression syntax, rather than allowing them only in a few special cases as before. In particular you can now pass a ROW() construct to a function that accepts a rowtype parameter. Internal generation of RowExprs fixes a number of corner cases that used to not work very well, such as referencing the whole-row result of a JOIN or subquery. This represents a further step in the work I started a month or so back to make rowtype values into first-class citizens.
2004-05-11 00:44:49 +02:00
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
First phase of work on array improvements. ARRAY[x,y,z] constructor expressions, ARRAY(sub-SELECT) expressions, some array functions. Polymorphic functions using ANYARRAY/ANYELEMENT argument and return types. Some regression tests in place, documentation is lacking. Joe Conway, with some kibitzing from Tom Lane.
2003-04-09 01:20:04 +02:00
return TRUE;
}
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
case T_RowCompareExpr:
{
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
RowCompareExpr *expr = (RowCompareExpr *) node;
Implement SQL-compliant treatment of row comparisons for < <= > >= cases (previously we only did = and <> correctly). Also, allow row comparisons with any operators that are in btree opclasses, not only those with these specific names. This gets rid of a whole lot of indefensible assumptions about the behavior of particular operators based on their names ... though it's still true that IN and NOT IN expand to "= ANY". The patch adds a RowCompareExpr expression node type, and makes some changes in the representation of ANY/ALL/ROWCOMPARE SubLinks so that they can share code with RowCompareExpr. I have not yet done anything about making RowCompareExpr an indexable operator, but will look at that soon. initdb forced due to changes in stored rules.
2005-12-28 02:30:02 +01:00
if (!exec_simple_check_node((Node *) expr->largs))
return FALSE;
if (!exec_simple_check_node((Node *) expr->rargs))
return FALSE;
return TRUE;
}
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
case T_CoalesceExpr:
{
pgindent run.
2003-08-04 02:43:34 +02:00
CoalesceExpr *expr = (CoalesceExpr *) node;
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
Add Oracle-compatible GREATEST and LEAST functions. Pavel Stehule
2005-06-27 00:05:42 +02:00
case T_MinMaxExpr:
{
MinMaxExpr *expr = (MinMaxExpr *) node;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
Code review for XML patch. Instill a bit of sanity in the location of the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
2006-12-24 01:29:20 +01:00
case T_XmlExpr:
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
XmlExpr *expr = (XmlExpr *) node;
Code review for XML patch. Instill a bit of sanity in the location of the XmlExpr code in various lists, use a representation that has some hope of reverse-listing correctly (though it's still a de-escaping function shy of correctness), generally try to make it look more like Postgres coding conventions.
2006-12-24 01:29:20 +01:00
if (!exec_simple_check_node((Node *) expr->named_args))
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
COALESCE() and NULLIF() are now first-class expressions, not macros that turn into CASE expressions. They evaluate their arguments at most once. Patch by Kris Jurka, review and (very light) editorializing by me.
2003-02-16 03:30:39 +01:00
case T_NullIfExpr:
{
NullIfExpr *expr = (NullIfExpr *) node;
if (expr->opretset)
return FALSE;
if (!exec_simple_check_node((Node *) expr->args))
return FALSE;
return TRUE;
}
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_NullTest:
return exec_simple_check_node((Node *) ((NullTest *) node)->arg);
case T_BooleanTest:
return exec_simple_check_node((Node *) ((BooleanTest *) node)->arg);
Determine the set of constraints applied to a domain at executor startup, not in the parser; this allows ALTER DOMAIN to work correctly with domain constraint operations stored in rules. Rod Taylor; code review by Tom Lane.
2003-02-03 22:15:45 +01:00
case T_CoerceToDomain:
return exec_simple_check_node((Node *) ((CoerceToDomain *) node)->arg);
Reimplement CASE val WHEN compval1 THEN ... WHEN compval2 THEN ... END so that the 'val' is computed only once, per recent discussion. The speedup is not much when 'val' is just a simple variable, but could be significant for larger expressions. More importantly this avoids issues with multiple evaluations of a volatile 'val', and it allows the CASE expression to be reverse-listed in its original form by ruleutils.c.
2004-03-17 21:48:43 +01:00
case T_CoerceToDomainValue:
return TRUE;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
case T_List:
{
List *expr = (List *) node;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
ListCell *l;
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
foreach(l, expr)
{
if (!exec_simple_check_node(lfirst(l)))
return FALSE;
}
return TRUE;
}
Clean up handling of variable-free qual clauses. System now does the right thing with variable-free clauses that contain noncachable functions, such as 'WHERE random() < 0.5' --- these are evaluated once per potential output tuple. Expressions that contain only Params are now candidates to be indexscan quals --- for example, 'var = ($1 + 1)' can now be indexed. Cope with RelabelType nodes atop potential indexscan variables --- this oversight prevents 7.0.* from recognizing some potentially indexscanable situations.
2000-08-13 04:50:35 +02:00
pgindent run over code.
1999-05-25 18:15:34 +02:00
default:
return FALSE;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
}
/* ----------
* exec_simple_check_plan - Check if a plan is simple enough to
* be evaluated by ExecEvalExpr() instead
* of SPI.
* ----------
*/
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_simple_check_plan(PLpgSQL_expr *expr)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
{
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
CachedPlanSource *plansource;
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
PlannedStmt *stmt;
pgindent run over code.
1999-05-25 18:15:34 +02:00
Plan *plan;
TargetEntry *tle;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Initialize to "not simple", and remember the plan generation number we
* last checked. (If the query produces more or less than one parsetree
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
* we just leave expr_simple_generation set to 0.)
*/
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
expr->expr_simple_expr = NULL;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
expr->expr_simple_generation = 0;
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* 1. We can only evaluate queries that resulted in one single execution
* plan
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
if (list_length(expr->plan->plancache_list) != 1)
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
return;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
plansource = (CachedPlanSource *) linitial(expr->plan->plancache_list);
expr->expr_simple_generation = plansource->generation;
if (list_length(plansource->plan->stmt_list) != 1)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
return;
Make use of plancache module for SPI plans. In particular, since plpgsql uses SPI plans, this finally fixes the ancient gotcha that you can't drop and recreate a temp table used by a plpgsql function. Along the way, clean up SPI's API a little bit by declaring SPI plan pointers as "SPIPlanPtr" instead of "void *". This is cosmetic but helps to forestall simple programming mistakes. (I have changed some but not all of the callers to match; there are still some "void *"'s in contrib and the PL's. This is intentional so that we can see if anyone's compiler complains about it.)
2007-03-16 00:12:07 +01:00
stmt = (PlannedStmt *) linitial(plansource->plan->stmt_list);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
* 2. It must be a RESULT plan --> no scan's required
*/
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
if (!IsA(stmt, PlannedStmt))
Make exec_simple_check_plan() check for a null plan, so that it doesn't crash when processing a utility statement.
1999-07-04 03:03:01 +02:00
return;
Remove the Query structure from the executor's API. This allows us to stop storing mostly-redundant Query trees in prepared statements, portals, etc. To replace Query, a new node type called PlannedStmt is inserted by the planner at the top of a completed plan tree; this carries just the fields of Query that are still needed at runtime. The statement lists kept in portals etc. now consist of intermixed PlannedStmt and bare utility-statement nodes --- no Query. This incidentally allows us to remove some fields from Query and Plan nodes that shouldn't have been there in the first place. Still to do: simplify the execution-time range table; at the moment the range table passed to the executor still contains Query trees for subqueries. initdb forced due to change of stored rules.
2007-02-20 18:32:18 +01:00
plan = stmt->planTree;
Ye-old pgindent run. Same 4-space tabs.
2000-04-12 19:17:23 +02:00
if (!IsA(plan, Result))
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
return;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
exec_simple_check_plan() must not allow a plan having initPlans or subPlans to be considered 'simple'. This fixes reported problem with 'return exists (select 1 from foo);' in plpgsql function.
2000-03-11 07:19:00 +01:00
* 3. Can't have any subplan or qual clause, either
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
exec_simple_check_plan() must not allow a plan having initPlans or subPlans to be considered 'simple'. This fixes reported problem with 'return exists (select 1 from foo);' in plpgsql function.
2000-03-11 07:19:00 +01:00
if (plan->lefttree != NULL ||
plan->righttree != NULL ||
plan->initPlan != NULL ||
plan->qual != NULL ||
((Result *) plan)->resconstantqual != NULL)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
return;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
exec_simple_check_plan() must not allow a plan having initPlans or subPlans to be considered 'simple'. This fixes reported problem with 'return exists (select 1 from foo);' in plpgsql function.
2000-03-11 07:19:00 +01:00
* 4. The plan must have a single attribute as result
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Use the new List API function names throughout the backend, and disable the list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
2004-05-31 01:40:41 +02:00
if (list_length(plan->targetlist) != 1)
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
return;
Reimplement the linked list data structure used throughout the backend. In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
2004-05-26 06:41:50 +02:00
tle = (TargetEntry *) linitial(plan->targetlist);
exec_simple_check_plan() must not allow a plan having initPlans or subPlans to be considered 'simple'. This fixes reported problem with 'return exists (select 1 from foo);' in plpgsql function.
2000-03-11 07:19:00 +01:00
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
* 5. Check that all the nodes in the expression are non-scary.
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Phase 2 of read-only-plans project: restructure expression-tree nodes so that all executable expression nodes inherit from a common supertype Expr. This is somewhat of an exercise in code purity rather than any real functional advance, but getting rid of the extra Oper or Func node formerly used in each operator or function call should provide at least a little space and speed improvement. initdb forced by changes in stored-rules representation.
2002-12-12 16:49:42 +01:00
if (!exec_simple_check_node((Node *) tle->expr))
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
return;
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
* Yes - this is a simple expression. Mark it as such, and initialize
Fix possible crash at transaction end when a plpgsql function is used and then modified within the same transaction. The code was using a linked list of active PLpgSQL_expr structs, which was OK when it was written because plpgsql never released any parse data structures for the life of the backend. But since Neil fixed plpgsql's memory management, elements of the linked list could be freed, leading to crash when the list is chased. Per report and test case from Kris Jurka.
2006-03-02 06:34:12 +01:00
* state to "not valid in current transaction".
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
*/
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
expr->expr_simple_expr = tle->expr;
expr->expr_simple_state = NULL;
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
expr->expr_simple_id = -1;
Revise executor APIs so that all per-query state structure is built in a per-query memory context created by CreateExecutorState --- and destroyed by FreeExecutorState. This provides a final solution to the longstanding problem of memory leaked by various ExecEndNode calls.
2002-12-15 17:17:59 +01:00
/* Also stash away the expression result type */
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
expr->expr_simple_type = exprType((Node *) tle->expr);
Speedup of PL/pgSQL by calling ExecEvalExpr() directly instead of SPI_execp() for simple expressions. Jan
1999-01-27 17:15:22 +01:00
}
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
/*
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
* Validates compatibility of supplied TupleDesc pair by checking number and type
* of attributes.
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
*/
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
static void
validate_tupdesc_compat(TupleDesc expected, TupleDesc returned, const char *msg)
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
{
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
int i;
Fix unportable syntax used in recent patch. Per results from buildfarm member 'bear'.
2008-09-24 16:40:00 +02:00
const char *dropped_column_type = gettext_noop("n/a (dropped column)");
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
if (!expected || !returned)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("%s", _(msg))));
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
if (expected->natts != returned->natts)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("%s", _(msg)),
errdetail("Number of returned columns (%d) does not match "
"expected column count (%d).",
returned->natts, expected->natts)));
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
Improve plpgsql's ability to report tuple incompatibility problems. Volkan YAZICI
2008-09-09 17:14:08 +02:00
for (i = 0; i < expected->natts; i++)
if (expected->attrs[i]->atttypid != returned->attrs[i]->atttypid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("%s", _(msg)),
errdetail("Returned type %s does not match expected type "
"%s in column %s.",
OidIsValid(returned->attrs[i]->atttypid) ?
format_type_be(returned->attrs[i]->atttypid) :
_(dropped_column_type),
OidIsValid(expected->attrs[i]->atttypid) ?
format_type_be(expected->attrs[i]->atttypid) :
_(dropped_column_type),
NameStr(expected->attrs[i]->attname))));
Add expected tuple descriptor to ReturnSetInfo information for table functions, per suggestion from John Gray and Joe Conway. Also, fix plpgsql RETURN NEXT to verify that returned values match the expected tupdesc.
2002-08-31 01:59:46 +02:00
}
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
/* ----------
* exec_set_found Set the global found variable
* to true/false
* ----------
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
exec_set_found(PLpgSQL_execstate *estate, bool state)
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
{
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
PLpgSQL_var *var;
As proposed, here is the current version of PL/pgSQL. The test isn't that complete up to now, but I think it shows enough of the capabilities of the module. The Makefile assumes it is located in a directory under pgsql/src/pl. Since it includes Makefile.global and Makefile.port and doesn't use any own compiler/linker calls, it should build on most of our supported platforms (I only tested under Linux up to now). It requires flex and bison I think. Maybe we should ship prepared gram.c etc. like for the main parser too? Jan
1998-08-22 14:38:39 +02:00
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var = (PLpgSQL_var *) (estate->datums[estate->found_varno]);
Clean up a few places where Datums were being treated as pointers (and vice versa) without going through DatumGetPointer. Gavin Sherry, with Feng Tian.
2008-04-17 23:37:28 +02:00
var->value = PointerGetDatum(state);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
var->isnull = false;
}
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
/*
* plpgsql_create_econtext --- create an eval_econtext for the current function
*
* We may need to create a new eval_estate too, if there's not one already
* for the current (sub) transaction. The EState will be cleaned up at
* (sub) transaction end.
*/
static void
plpgsql_create_econtext(PLpgSQL_execstate *estate)
{
SubTransactionId my_subxid = GetCurrentSubTransactionId();
SimpleEstateStackEntry *entry = simple_estate_stack;
/* Create new EState if not one for current subxact */
if (entry == NULL ||
entry->xact_subxid != my_subxid)
{
MemoryContext oldcontext;
/* Stack entries are kept in TopTransactionContext for simplicity */
entry = (SimpleEstateStackEntry *)
MemoryContextAlloc(TopTransactionContext,
sizeof(SimpleEstateStackEntry));
/* But each EState should be a child of its CurTransactionContext */
oldcontext = MemoryContextSwitchTo(CurTransactionContext);
entry->xact_eval_estate = CreateExecutorState();
MemoryContextSwitchTo(oldcontext);
/* Assign a reasonably-unique ID to this EState */
entry->xact_estate_simple_id = simple_estate_id_counter++;
entry->xact_subxid = my_subxid;
entry->next = simple_estate_stack;
simple_estate_stack = entry;
}
/* Link plpgsql estate to it */
estate->eval_estate = entry->xact_eval_estate;
estate->eval_estate_simple_id = entry->xact_estate_simple_id;
/* And create a child econtext for the current function */
estate->eval_econtext = CreateExprContext(estate->eval_estate);
}
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
/*
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
* plpgsql_xact_cb --- post-transaction-commit-or-abort cleanup
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* If a simple-expression EState was created in the current transaction,
Fix possible crash at transaction end when a plpgsql function is used and then modified within the same transaction. The code was using a linked list of active PLpgSQL_expr structs, which was OK when it was written because plpgsql never released any parse data structures for the life of the backend. But since Neil fixed plpgsql's memory management, elements of the linked list could be freed, leading to crash when the list is chased. Per report and test case from Kris Jurka.
2006-03-02 06:34:12 +01:00
* it has to be cleaned up.
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
*/
void
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
plpgsql_xact_cb(XactEvent event, void *arg)
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
{
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If we are doing a clean transaction shutdown, free the EState (so that
* any remaining resources will be released correctly). In an abort, we
* expect the regular abort recovery procedures to release everything of
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
* interest. We don't need to free the individual stack entries since
* TopTransactionContext is about to go away anyway.
*
* Note: if plpgsql_subxact_cb is doing its job, there should be at most
* one stack entry, but we may as well code this as a loop.
Restructure subtransaction handling to reduce resource consumption, as per recent discussions. Invent SubTransactionIds that are managed like CommandIds (ie, counter is reset at start of each top transaction), and use these instead of TransactionIds to keep track of subtransaction status in those modules that need it. This means that a subtransaction does not need an XID unless it actually inserts/modifies rows in the database. Accordingly, don't assign it an XID nor take a lock on the XID until it tries to do that. This saves a lot of overhead for subtransactions that are only used for error recovery (eg plpgsql exceptions). Also, arrange to release a subtransaction's XID lock as soon as the subtransaction exits, in both the commit and abort cases. This avoids holding many unique locks after a long series of subtransactions. The price is some additional overhead in XactLockTableWait, but that seems acceptable. Finally, restructure the state machine in xact.c to have a more orthogonal set of states for subtransactions.
2004-09-16 18:58:44 +02:00
*/
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
if (event != XACT_EVENT_ABORT)
{
while (simple_estate_stack != NULL)
{
FreeExecutorState(simple_estate_stack->xact_eval_estate);
simple_estate_stack = simple_estate_stack->next;
}
}
else
simple_estate_stack = NULL;
}
/*
* plpgsql_subxact_cb --- post-subtransaction-commit-or-abort cleanup
*
* If a simple-expression EState was created in the current subtransaction,
* it has to be cleaned up.
*/
void
plpgsql_subxact_cb(SubXactEvent event, SubTransactionId mySubid,
SubTransactionId parentSubid, void *arg)
{
if (event == SUBXACT_EVENT_START_SUB)
return;
if (simple_estate_stack != NULL &&
simple_estate_stack->xact_subxid == mySubid)
{
SimpleEstateStackEntry *next;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Fix up plpgsql's "simple expression" evaluation mechanism so that it behaves safely in the presence of subtransactions. To ensure that any ExprContext shutdown callbacks are called at the right times, we have to have a separate EState for each level of subtransaction. Per "TupleDesc reference leak" bug report from Stefan Kaltenbrunner. Although I'm convinced the code is wrong as far back as 8.0, it doesn't seem that there are any ways for the problem to really manifest before 8.2: AFAICS, 8.0 and 8.1 only use the ExprContextCallback mechanism to handle set-returning functions, which cannot usefully be executed in a "simple expression" anyway. Hence, no backpatch before 8.2 --- the risk of unforeseen breakage seems to outweigh the chance of fixing something.
2007-01-28 17:15:49 +01:00
if (event == SUBXACT_EVENT_COMMIT_SUB)
FreeExecutorState(simple_estate_stack->xact_eval_estate);
next = simple_estate_stack->next;
pfree(simple_estate_stack);
simple_estate_stack = next;
}
Restructure plpgsql's caching of 'simple' expression evaluation trees to be less dangerous, and often faster as well. ExprState trees are not kept across transaction boundaries; this eliminates problems with resource leakage in failed transactions. But by keeping them in a per-transaction EState, we can safely arrange for a single ExprState to be shared by all the expression evaluations done in a given plpgsql function call. (Formerly it seemed necessary to create and destroy an ExprState for each exec_eval_simple_expr() call.) This saves time in any scenario where a plpgsql function executes more than one expression. Seems to be about as fast as 7.3 for simple cases, and significantly faster for functions that do a lot of calculations.
2003-09-29 01:37:45 +02:00
}
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
Fix an ancient logic error in plpgsql's exec_stmt_block: it thought it could get away with not (re)initializing a local variable if the variable is marked "isconst" and not "isnull". Unfortunately it makes this decision after having already freed the old value, meaning that something like for i in 1..10 loop declare c constant text := 'hi there'; leads to subsequent accesses to freed memory, and hence probably crashes. (In particular, this is why Asif Ali Rehman's bug leads to crash and not just an unexpectedly-NULL value for SQLERRM: SQLERRM is marked CONSTANT and so triggers this error.) The whole thing seems wrong on its face anyway: CONSTANT means that you can't change the variable inside the block, not that the initializer expression is guaranteed not to change value across successive block entries. Hence, remove the "optimization" instead of trying to fix it.
2007-02-08 19:37:30 +01:00
/*
* free_var --- pfree any pass-by-reference value of the variable.
*
* This should always be followed by some assignment to var->value,
* as it leaves a dangling pointer.
*/
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
static void
Re-run pgindent, fixing a problem where comment lines after a blank comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2005-11-22 19:17:34 +01:00
free_var(PLpgSQL_var *var)
Implement two new special variables in PL/PgSQL: SQLSTATE and SQLERRM. These contain the SQLSTATE and error message of the current exception, respectively. They are scope-local variables that are only defined in exception handlers (so attempting to reference them outside an exception handler is an error). Update the regression tests and the documentation. Also, do some minor related cleanup: export an unpack_sql_state() function from the backend and use it to unpack a SQLSTATE into a string, and add a free_var() function to pl_exec.c Original patch from Pavel Stehule, review by Neil Conway.
2005-06-10 18:23:11 +02:00
{
if (var->freeval)
{
pfree(DatumGetPointer(var->value));
var->freeval = false;
}
}
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
Make plpgsql support FOR over a query specified by a cursor declaration, for improved compatibility with Oracle. Pavel Stehule, with some fixes by me.
2008-04-07 01:43:29 +02:00
/*
* free old value of a text variable and assign new value from C string
*/
static void
assign_text_var(PLpgSQL_var *var, const char *str)
{
free_var(var);
var->value = CStringGetTextDatum(str);
var->isnull = false;
var->freeval = true;
}
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
/*
* exec_eval_using_params --- evaluate params of USING clause
*/
static PreparedParamsData *
exec_eval_using_params(PLpgSQL_execstate *estate, List *params)
{
PreparedParamsData *ppd;
int nargs;
int i;
ListCell *lc;
ppd = (PreparedParamsData *) palloc(sizeof(PreparedParamsData));
nargs = list_length(params);
ppd->nargs = nargs;
ppd->types = (Oid *) palloc(nargs * sizeof(Oid));
ppd->values = (Datum *) palloc(nargs * sizeof(Datum));
ppd->nulls = (char *) palloc(nargs * sizeof(char));
ppd->freevals = (bool *) palloc(nargs * sizeof(bool));
i = 0;
foreach(lc, params)
{
PLpgSQL_expr *param = (PLpgSQL_expr *) lfirst(lc);
bool isnull;
ppd->values[i] = exec_eval_expr(estate, param,
&isnull,
&ppd->types[i]);
ppd->nulls[i] = isnull ? 'n' : ' ';
ppd->freevals[i] = false;
/* pass-by-ref non null values must be copied into plpgsql context */
if (!isnull)
{
int16 typLen;
bool typByVal;
get_typlenbyval(ppd->types[i], &typLen, &typByVal);
if (!typByVal)
{
ppd->values[i] = datumCopy(ppd->values[i], typByVal, typLen);
ppd->freevals[i] = true;
}
}
exec_eval_cleanup(estate);
i++;
}
return ppd;
}
/*
* free_params_data --- pfree all pass-by-reference values used in USING clause
*/
static void
free_params_data(PreparedParamsData *ppd)
{
int i;
for (i = 0; i < ppd->nargs; i++)
{
if (ppd->freevals[i])
pfree(DatumGetPointer(ppd->values[i]));
}
pfree(ppd->types);
pfree(ppd->values);
pfree(ppd->nulls);
pfree(ppd->freevals);
pfree(ppd);
}
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
/*
* Open portal for dynamic query
*/
static Portal
exec_dynquery_with_params(PLpgSQL_execstate *estate, PLpgSQL_expr *dynquery,
List *params)
{
Portal portal;
Datum query;
bool isnull;
Oid restype;
char *querystr;
/*
* Evaluate the string expression after the EXECUTE keyword. Its result
* is the querystring we have to execute.
*/
query = exec_eval_expr(estate, dynquery, &isnull, &restype);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
errmsg("cannot EXECUTE a null querystring")));
/* Get the C-String representation */
querystr = convert_value_to_string(query, restype);
exec_eval_cleanup(estate);
/*
* Open an implicit cursor for the query. We use SPI_cursor_open_with_args
* even when there are no params, because this avoids making and freeing
* one copy of the plan.
*/
if (params)
{
PreparedParamsData *ppd;
ppd = exec_eval_using_params(estate, params);
portal = SPI_cursor_open_with_args(NULL,
querystr,
ppd->nargs, ppd->types,
ppd->values, ppd->nulls,
estate->readonly_func, 0);
free_params_data(ppd);
}
else
{
portal = SPI_cursor_open_with_args(NULL,
querystr,
0, NULL,
NULL, NULL,
estate->readonly_func, 0);
}
if (portal == NULL)
elog(ERROR, "could not open implicit cursor for query \"%s\": %s",
querystr, SPI_result_code_string(SPI_result));
pfree(querystr);
return portal;
}