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

6031 lines
155 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
*
Stamp copyrights for year 2011.
2011-01-01 19:18:15 +01:00
* Portions Copyright (c) 1996-2011, 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 cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/pl/plpgsql/src/pl_exec.c
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"
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
#include "access/tupconvert.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"
Avoid including miscadmin.h into plpgsql.h; instead include it into the two source files that need it.
2009-08-04 23:22:46 +02:00
#include "miscadmin.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"
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
#include "storage/proc.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"
Fix executor/spi.h to follow our usual conventions for include files, ie, not include postgres.h nor anything else it doesn't directly need. Add #includes to calling files as needed to compensate. Per my proposal of yesterday. This should be noted as a source code change in the 8.4 release notes, since it's likely to require changes in add-on modules.
2009-01-07 14:44:37 +01:00
#include "utils/datum.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/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"
Move Trigger and TriggerDesc structs out of rel.h into a new reltrigger.h This lets us stop including rel.h into execnodes.h, which is a widely used header.
2011-02-23 18:18:09 +01:00
#include "utils/rel.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
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* that the abort mechanisms clean it all up). Furthermore, any exception
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
* block within a function has to have its own eval_econtext separate from
* the containing function's, so that we can clean up ExprContext callbacks
* properly at subtransaction exit. We maintain a stack that tracks the
* individual econtexts so that we can clean up correctly at subxact exit.
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
*
* 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 the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
typedef struct SimpleEcontextStackEntry
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
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
ExprContext *stack_econtext; /* a stacked econtext */
SubTransactionId xact_subxid; /* ID for current subxact */
struct SimpleEcontextStackEntry *next; /* next stack entry up */
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
} SimpleEcontextStackEntry;
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
static EState *simple_eval_estate = NULL;
static SimpleEcontextStackEntry *simple_econtext_stack = 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
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,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
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);
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
static int exec_stmt_foreach_a(PLpgSQL_execstate *estate,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
PLpgSQL_stmt_foreach_a *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);
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
static void exec_assign_c_string(PLpgSQL_execstate *estate,
PLpgSQL_datum *target,
const char *str);
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_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 *typeid,
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
int32 *typetypmod,
pgindent run.
2003-08-04 02:43:34 +02:00
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,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Portal portal, bool prefetch_ok);
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
static ParamListInfo setup_param_list(PLpgSQL_execstate *estate,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
PLpgSQL_expr *expr);
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
static void plpgsql_param_fetch(ParamListInfo params, int paramid);
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);
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);
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
static void plpgsql_destroy_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,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
List *params);
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
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,
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
PLpgSQL_expr *dynquery, List *params,
const char *portalname, int cursorOptions);
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")));
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
*/
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
HeapTuple rettup = (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
TupleDesc tupdesc;
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
TupleConversionMap *tupmap;
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
switch (get_call_result_type(fcinfo, NULL, &tupdesc))
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
tupmap = convert_tuples_by_position(estate.rettupdesc,
tupdesc,
gettext_noop("returned record type does not match expected record type"));
/* it might need conversion */
if (tupmap)
rettup = do_convert_tuple(rettup, tupmap);
/* no need to free map, we're about to return anyway */
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
*/
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
estate.retval = PointerGetDatum(SPI_returntuple(rettup, 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 */
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
plpgsql_destroy_econtext(&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
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* We make the tupdescs available in both records even though only one may
* have a value. This allows parsing of record references to succeed in
* functions that are used for multiple trigger types. For example, we
* might have a test like "if (TG_OP = 'INSERT' and NEW.foo = 'xyz')",
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
* which should parse regardless of the current trigger type.
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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
rec_new->tupdesc = trigdata->tg_relation->rd_att;
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->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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
rec_old->tupdesc = trigdata->tg_relation->rd_att;
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->freetupdesc = false;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
Fix sloppy usage of TRIGGER_FIRED_BEFORE/TRIGGER_FIRED_AFTER. Various places were testing TRIGGER_FIRED_BEFORE() where what they really meant was !TRIGGER_FIRED_AFTER(), or vice versa. This needs to be cleaned up because there are about to be more than two possible states. We might want to note this in the 9.1 release notes as something for trigger authors to double-check. For consistency's sake I also changed some places that assumed that TRIGGER_FIRED_FOR_ROW and TRIGGER_FIRED_FOR_STATEMENT are necessarily mutually exclusive; that's not in immediate danger of breaking, but it's still sloppier than it should be. Extracted from Dean Rasheed's patch for triggers on views. I'm committing this separately since it's an identifiable separate issue, and is the only reason for the patch to touch most of these particular files.
2010-10-08 19:27:31 +02:00
if (!TRIGGER_FIRED_FOR_ROW(trigdata->tg_event))
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
{
/*
* Per-statement triggers don't use OLD/NEW variables
*/
rec_new->tup = NULL;
rec_old->tup = 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_old->tup = 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_old->tup = trigdata->tg_trigtuple;
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_old->tup = trigdata->tg_trigtuple;
}
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");
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
else if (TRIGGER_FIRED_INSTEAD(trigdata->tg_event))
var->value = CStringGetTextDatum("INSTEAD OF");
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
Support triggers on views. This patch adds the SQL-standard concept of an INSTEAD OF trigger, which is fired instead of performing a physical insert/update/delete. The trigger function is passed the entire old and/or new rows of the view, and must figure out what to do to the underlying tables to implement the update. So this feature can be used to implement updatable views using trigger programming style rather than rule hacking. In passing, this patch corrects the names of some columns in the information_schema.triggers view. It seems the SQL committee renamed them somewhere between SQL:99 and SQL:2003. Dean Rasheed, reviewed by Bernd Helmle; some additional hacking by me.
2010-10-10 19:43:33 +02:00
elog(ERROR, "unrecognized trigger execution time: not BEFORE, AFTER, or INSTEAD OF");
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
var = (PLpgSQL_var *) (estate.datums[func->tg_argv_varno]);
if (trigdata->tg_trigger->tgnargs > 0)
{
/*
* For historical reasons, tg_argv[] subscripts start at zero not one.
* So we can't use construct_array().
*/
int nelems = trigdata->tg_trigger->tgnargs;
Datum *elems;
int dims[1];
int lbs[1];
elems = palloc(sizeof(Datum) * nelems);
for (i = 0; i < nelems; i++)
elems[i] = CStringGetTextDatum(trigdata->tg_trigger->tgargs[i]);
dims[0] = nelems;
lbs[0] = 0;
var->value = PointerGetDatum(construct_md_array(elems, NULL,
1, dims, lbs,
TEXTOID,
-1, false, 'i'));
var->isnull = false;
var->freeval = true;
}
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
else
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
var->value = (Datum) 0;
var->isnull = true;
var->freeval = false;
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")));
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
*/
Fix sloppy usage of TRIGGER_FIRED_BEFORE/TRIGGER_FIRED_AFTER. Various places were testing TRIGGER_FIRED_BEFORE() where what they really meant was !TRIGGER_FIRED_AFTER(), or vice versa. This needs to be cleaned up because there are about to be more than two possible states. We might want to note this in the 9.1 release notes as something for trigger authors to double-check. For consistency's sake I also changed some places that assumed that TRIGGER_FIRED_FOR_ROW and TRIGGER_FIRED_FOR_STATEMENT are necessarily mutually exclusive; that's not in immediate danger of breaking, but it's still sloppier than it should be. Extracted from Dean Rasheed's patch for triggers on views. I'm committing this separately since it's an identifiable separate issue, and is the only reason for the patch to touch most of these particular files.
2010-10-08 19:27:31 +02:00
if (estate.retisnull || !TRIGGER_FIRED_FOR_ROW(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 cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
TupleConversionMap *tupmap;
rettup = (HeapTuple) DatumGetPointer(estate.retval);
/* check rowtype compatibility */
tupmap = convert_tuples_by_position(estate.rettupdesc,
trigdata->tg_relation->rd_att,
gettext_noop("returned row structure does not match the structure of the triggering table"));
/* it might need conversion */
if (tupmap)
rettup = do_convert_tuple(rettup, tupmap);
/* no need to free map, we're about to return anyway */
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 */
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
rettup = SPI_copytuple(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
}
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 */
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
plpgsql_destroy_econtext(&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
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;
/* 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)
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02: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",
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->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,
Message wordsmithing
2009-02-18 12:33:04 +01:00
_(estate->err_text));
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
}
else
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
/*
* translator: last %s is a phrase such as "while storing call
* arguments into local variables"
*/
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\" %s",
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->func->fn_name,
Message wordsmithing
2009-02-18 12:33:04 +01:00
_(estate->err_text));
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
}
}
else if (estate->err_stmt != NULL)
{
/* translator: last %s is a plpgsql statement type name */
errcontext("PL/pgSQL function \"%s\" line %d at %s",
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->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\"",
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->func->fn_name);
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
}
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:
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);
rec->freetup = false;
}
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
if (rec->freetupdesc)
{
FreeTupleDesc(rec->tupdesc);
rec->freetupdesc = 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;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ErrorData *save_cur_error = estate->cur_error;
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 the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Revert to outer eval_econtext. (The inner one was
* automatically cleaned up during subxact exit.)
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +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
estate->eval_econtext = old_eval_econtext;
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;
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
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
/* Must clean up the econtext too */
exec_eval_cleanup(estate);
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
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
/*
* Also set up cur_error so the error data is accessible
* inside the handler.
*/
estate->cur_error = edata;
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
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;
}
}
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
/*
* Restore previous state of cur_error, whether or not we executed
* a handler. This is needed in case an error got thrown from
* some inner block's exception handler.
*/
estate->cur_error = save_cur_error;
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 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();
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
Assert(save_cur_error == estate->cur_error);
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
}
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:
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:
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Fix plpgsql's EXIT so that an EXIT without a label only matches a loop, never a BEGIN block. This is required for Oracle compatibility and is also plainly stated to be the behavior by our original documentation (up until 8.1, in which the docs were adjusted to match the code's behavior; but actually the old docs said the correct thing and the code was wrong). Not back-patched because this introduces an incompatibility that could break working applications. Requires release note.
2009-05-02 19:27:57 +02:00
/*
* This is intentionally different from the handling of RC_EXIT
* for loops: to match a block, we require a match by label.
*/
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (estate->exitlabel == NULL)
Fix plpgsql's EXIT so that an EXIT without a label only matches a loop, never a BEGIN block. This is required for Oracle compatibility and is also plainly stated to be the behavior by our original documentation (up until 8.1, in which the docs were adjusted to match the code's behavior; but actually the old docs said the correct thing and the code was wrong). Not back-patched because this introduces an incompatibility that could break working applications. Requires release note.
2009-05-02 19:27:57 +02:00
return PLPGSQL_RC_EXIT;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
if (block->label == NULL)
return PLPGSQL_RC_EXIT;
Fix plpgsql's EXIT so that an EXIT without a label only matches a loop, never a BEGIN block. This is required for Oracle compatibility and is also plainly stated to be the behavior by our original documentation (up until 8.1, in which the docs were adjusted to match the code's behavior; but actually the old docs said the correct thing and the code was wrong). Not back-patched because this introduces an incompatibility that could break working applications. Requires release note.
2009-05-02 19:27:57 +02:00
if (strcmp(block->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
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;
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
case PLPGSQL_STMT_FOREACH_A:
rc = exec_stmt_foreach_a(estate, (PLpgSQL_stmt_foreach_a *) 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
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
/*
* GET STACKED DIAGNOSTICS is only valid inside an exception handler.
*
* Note: we trust the grammar to have disallowed the relevant item kinds
* if not is_stacked, otherwise we'd dump core below.
*/
if (stmt->is_stacked && estate->cur_error == NULL)
ereport(ERROR,
(errcode(ERRCODE_STACKED_DIAGNOSTICS_ACCESSED_WITHOUT_ACTIVE_HANDLER),
errmsg("GET STACKED DIAGNOSTICS cannot be used outside an exception handler")));
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:
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:
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
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
case PLPGSQL_GETDIAG_ERROR_CONTEXT:
exec_assign_c_string(estate, var,
estate->cur_error->context);
break;
case PLPGSQL_GETDIAG_ERROR_DETAIL:
exec_assign_c_string(estate, var,
estate->cur_error->detail);
break;
case PLPGSQL_GETDIAG_ERROR_HINT:
exec_assign_c_string(estate, var,
estate->cur_error->hint);
break;
case PLPGSQL_GETDIAG_RETURNED_SQLSTATE:
exec_assign_c_string(estate, var,
unpack_sql_state(estate->cur_error->sqlerrcode));
break;
case PLPGSQL_GETDIAG_MESSAGE_TEXT:
exec_assign_c_string(estate, var,
estate->cur_error->message);
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:
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
elog(ERROR, "unrecognized diagnostic item kind: %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 */
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Datum t_val;
Oid t_oid;
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
t_val = exec_eval_expr(estate, stmt->t_expr, &isnull, &t_oid);
t_var = (PLpgSQL_var *) estate->datums[stmt->t_varno];
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* 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.
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
*/
if (t_var->datatype->typoid != t_oid)
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
t_var->datatype = plpgsql_build_datatype(t_oid,
-1,
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
estate->func->fn_input_collation);
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
/* 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);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
bool value;
Support SQL/PSM-compatible CASE statement in plpgsql. Pavel Stehule
2008-05-16 00:39:49 +02:00
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
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;
Fix plpgsql's EXIT so that an EXIT without a label only matches a loop, never a BEGIN block. This is required for Oracle compatibility and is also plainly stated to be the behavior by our original documentation (up until 8.1, in which the docs were adjusted to match the code's behavior; but actually the old docs said the correct thing and the code was wrong). Not back-patched because this introduces an incompatibility that could break working applications. Requires release note.
2009-05-02 19:27:57 +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;
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
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
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
var = (PLpgSQL_var *) (estate->datums[stmt->var->dno]);
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
/*
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("BY value 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
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
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
if (rc == 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
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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
ParamListInfo paramLI;
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 portal;
int rc;
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),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
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
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Set up ParamListInfo (note this is only carrying a hook function, not
* any actual data values, at this point)
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
paramLI = setup_param_list(estate, query);
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
/*
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
* Open the cursor (the paramlist will get copied into the portal)
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
portal = SPI_cursor_open_with_paramlist(curname, query->plan,
paramLI,
estate->readonly_func);
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 (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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/* don't need paramlist any more */
if (paramLI)
pfree(paramLI);
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);
/* ----------
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane pointed out. The bug affects FOR statement variants too, because you can close an implicitly created cursor too by guessing the "<unnamed portal X>" name created for it. To fix that, "pin" the portal to prevent it from being dropped while it's being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is the oldest supported version.
2010-07-05 11:27:18 +02:00
* Close portal, and restore cursor variable if it was initially 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
* ----------
*/
SPI_cursor_close(portal);
if (curname == NULL)
{
free_var(curvar);
curvar->value = (Datum) 0;
curvar->isnull = true;
}
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 FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
/* ----------
* exec_stmt_foreach_a Loop over elements or slices of an array
*
* When looping over elements, the loop variable is the same type that the
* array stores (eg: integer), when looping through slices, the loop variable
* is an array of size and dimensions to match the size of the slice.
* ----------
*/
static int
exec_stmt_foreach_a(PLpgSQL_execstate *estate, PLpgSQL_stmt_foreach_a *stmt)
{
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
ArrayType *arr;
Oid arrtype;
PLpgSQL_datum *loop_var;
Oid loop_var_elem_type;
bool found = false;
int rc = PLPGSQL_RC_OK;
ArrayIterator array_iterator;
Oid iterator_result_type;
Datum value;
bool isnull;
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
/* get the value of the array expression */
value = exec_eval_expr(estate, stmt->expr, &isnull, &arrtype);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
Message style improvements
2011-05-20 23:50:35 +02:00
errmsg("FOREACH expression must not be null")));
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
/* check the type of the expression - must be an array */
if (!OidIsValid(get_element_type(arrtype)))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("FOREACH expression must yield an array, not type %s",
format_type_be(arrtype))));
/*
* We must copy the array, else it will disappear in exec_eval_cleanup.
* This is annoying, but cleanup will certainly happen while running the
* loop body, so we have little choice.
*/
arr = DatumGetArrayTypePCopy(value);
/* Clean up any leftover temporary memory */
exec_eval_cleanup(estate);
/* Slice dimension must be less than or equal to array dimension */
if (stmt->slice < 0 || stmt->slice > ARR_NDIM(arr))
ereport(ERROR,
(errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errmsg("slice dimension (%d) is out of the valid range 0..%d",
stmt->slice, ARR_NDIM(arr))));
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
/* Set up the loop variable and see if it is of an array type */
loop_var = estate->datums[stmt->varno];
if (loop_var->dtype == PLPGSQL_DTYPE_REC ||
loop_var->dtype == PLPGSQL_DTYPE_ROW)
{
/*
* Record/row variable is certainly not of array type, and might not
* be initialized at all yet, so don't try to get its type
*/
loop_var_elem_type = InvalidOid;
}
else
loop_var_elem_type = get_element_type(exec_get_datum_type(estate,
loop_var));
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Sanity-check the loop variable type. We don't try very hard here, and
* should not be too picky since it's possible that exec_assign_value can
* coerce values of different types. But it seems worthwhile to complain
* if the array-ness of the loop variable is not right.
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
*/
if (stmt->slice > 0 && loop_var_elem_type == InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errmsg("FOREACH ... SLICE loop variable must be of an array type")));
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
if (stmt->slice == 0 && loop_var_elem_type != InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
errmsg("FOREACH loop variable must not be of an array type")));
Add FOREACH IN ARRAY looping to plpgsql. (I'm not entirely sure that we've finished bikeshedding the syntax details, but the functionality seems OK.) Pavel Stehule, reviewed by Stephen Frost and Tom Lane
2011-02-16 07:52:04 +01:00
/* Create an iterator to step through the array */
array_iterator = array_create_iterator(arr, stmt->slice);
/* Identify iterator result type */
if (stmt->slice > 0)
{
/* When slicing, nominal type of result is same as array type */
iterator_result_type = arrtype;
}
else
{
/* Without slicing, results are individual array elements */
iterator_result_type = ARR_ELEMTYPE(arr);
}
/* Iterate over the array elements or slices */
while (array_iterate(array_iterator, &value, &isnull))
{
found = true; /* looped at least once */
/* Assign current element/slice to the loop variable */
exec_assign_value(estate, loop_var, value, iterator_result_type,
&isnull);
/* In slice case, value is temporary; must free it to avoid leakage */
if (stmt->slice > 0)
pfree(DatumGetPointer(value));
/*
* Execute the statements
*/
rc = exec_stmts(estate, stmt->body);
/* Handle the return code */
if (rc == PLPGSQL_RC_RETURN)
break; /* break out of the loop */
else if (rc == PLPGSQL_RC_EXIT)
{
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 */
estate->exitlabel = NULL;
rc = PLPGSQL_RC_OK;
}
/*
* 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.
*/
break;
}
else if (rc == PLPGSQL_RC_CONTINUE)
{
if (estate->exitlabel == NULL)
/* unlabelled continue, so re-run the current loop */
rc = PLPGSQL_RC_OK;
else if (stmt->label != NULL &&
strcmp(stmt->label, estate->exitlabel) == 0)
{
/* label matches named continue, so re-run loop */
estate->exitlabel = NULL;
rc = PLPGSQL_RC_OK;
}
else
{
/*
* 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.
*/
break;
}
}
}
/* Release temporary memory, including the array value */
array_free_iterator(array_iterator);
pfree(arr);
/*
* Set the FOUND variable to indicate the result of executing the loop
* (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.
*/
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
/* ----------
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
/*
Fix inconsistent capitalization of "PL/pgSQL". Josh Kupershmidt
2010-09-23 03:57:37 +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));
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
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
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
TupleDesc tupdesc;
int natts;
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
tuplestore_putvalues(estate->tuple_store, tupdesc,
&retval, &isNull);
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;
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
TupleConversionMap *tupmap;
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),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
errdetail("The tuple structure of a not-yet-assigned"
" record is indeterminate.")));
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
tupmap = convert_tuples_by_position(rec->tupdesc,
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;
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
/* it might need conversion */
if (tupmap)
{
tuple = do_convert_tuple(tuple, tupmap);
free_conversion_map(tupmap);
}
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_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
tuplestore_putvalues(estate->tuple_store, tupdesc,
&retval, &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
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))
{
tuplestore_puttuple(estate->tuple_store, tuple);
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;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
uint32 processed = 0;
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
TupleConversionMap *tupmap;
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,
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
stmt->params, NULL, 0);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
}
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 cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
tupmap = convert_tuples_by_position(portal->tupDesc,
estate->rettupdesc,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
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
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;
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];
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
if (tupmap)
tuple = do_convert_tuple(tuple, tupmap);
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);
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
if (tupmap)
heap_freetuple(tuple);
Add PL/PgSQL FOUND and GET DIAGNOSTICS support for RETURN QUERY statement Pavel Stehule
2009-02-05 16:25:49 +01:00
processed++;
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_freetuptable(SPI_tuptable);
}
Improve plpgsql's ability to cope with rowtypes containing dropped columns, by supporting conversions in places that used to demand exact rowtype match. Since this issue is certain to come up elsewhere (in fact, already has, in ExecEvalConvertRowtype), factor out the support code into new core functions for tuple conversion. I chose to put these in a new source file since heaptuple.c is already overly long. Heavily revised version of a patch by Pavel Stehule.
2009-08-06 22:44:32 +02:00
if (tupmap)
free_conversion_map(tupmap);
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_freetuptable(SPI_tuptable);
SPI_cursor_close(portal);
Add PL/PgSQL FOUND and GET DIAGNOSTICS support for RETURN QUERY statement Pavel Stehule
2009-02-05 16:25:49 +01:00
estate->eval_processed = processed;
exec_set_found(estate, processed != 0);
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
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;
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
ResourceOwner oldowner;
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
/*
* 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
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Switch to the right memory context and resource owner for storing the
* tuplestore for return set. If we're within a subtransaction opened for
* an exception-block, for example, we must still create the tuplestore in
* the resource owner that was active when this function was entered, and
* not in the subtransaction resource owner.
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01: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
oldcxt = MemoryContextSwitchTo(estate->tuple_store_cxt);
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
oldowner = CurrentResourceOwner;
CurrentResourceOwner = estate->tuple_store_owner;
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);
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
CurrentResourceOwner = oldowner;
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)
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
{
if (estate->cur_error != NULL)
ReThrowError(estate->cur_error);
/* oops, we're not inside a handler */
ereport(ERROR,
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
(errcode(ERRCODE_STACKED_DIAGNOSTICS_ACCESSED_WITHOUT_ACTIVE_HANDLER),
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
errmsg("RAISE without parameters cannot be used outside an exception handler")));
}
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)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
StringInfoData ds;
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
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
Replace PLpgSQL_dstring by StringInfo. Replace redundant PLpgSQL_dstring functionality with StringInfo. Patch by Pavel Stehule. Review by Joe Conway.
2009-07-22 04:31:38 +02:00
initStringInfo(&ds);
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
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] == '%')
{
Replace PLpgSQL_dstring by StringInfo. Replace redundant PLpgSQL_dstring functionality with StringInfo. Patch by Pavel Stehule. Review by Joe Conway.
2009-07-22 04:31:38 +02:00
appendStringInfoChar(&ds, '%');
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
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),
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
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,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(PLpgSQL_expr *) lfirst(current_param),
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
&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);
Replace PLpgSQL_dstring by StringInfo. Replace redundant PLpgSQL_dstring functionality with StringInfo. Patch by Pavel Stehule. Review by Joe Conway.
2009-07-22 04:31:38 +02:00
appendStringInfoString(&ds, extval);
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
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
Replace PLpgSQL_dstring by StringInfo. Replace redundant PLpgSQL_dstring functionality with StringInfo. Patch by Pavel Stehule. Review by Joe Conway.
2009-07-22 04:31:38 +02:00
appendStringInfoChar(&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")));
Replace PLpgSQL_dstring by StringInfo. Replace redundant PLpgSQL_dstring functionality with StringInfo. Patch by Pavel Stehule. Review by Joe Conway.
2009-07-22 04:31:38 +02:00
err_message = ds.data;
/* No pfree(ds.data), 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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("RAISE statement option cannot be null")));
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
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),
Replace errdetail("%s", ...) with errdetail_internal("%s", ...). There may be some other places where we should use errdetail_internal, but they'll have to be evaluated case-by-case. This commit just hits a bunch of places where invoking gettext is obviously a waste of cycles.
2011-07-16 20:21:12 +02:00
(err_detail != NULL) ? errdetail_internal("%s", err_detail) : 0,
Don't pass strings directly to errdetail() and errhint() - use %s to unescape them. Fixes a potential security issue (in as yet unreleased code)
2008-11-20 16:36:22 +01:00
(err_hint != NULL) ? errhint("%s", 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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/* this link will be restored at exit from plpgsql_call_handler */
func->cur_estate = estate;
estate->func = func;
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;
Modify the handling of RAISE without parameters so that the error it throws can be caught in the same places that could catch an ordinary RAISE ERROR in the same location. The previous coding insisted on throwing the error from the block containing the active exception handler; which is arguably more surprising, and definitely unlike Oracle's behavior. Not back-patching, since this is a pretty obscure corner case. The risk of breaking somebody's code in a minor version update seems to outweigh any possible benefit. Piyush Newe, reviewed by David Fetter
2010-08-09 04:25:07 +02:00
estate->cur_error = 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
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;
Previous fix for temporary file management broke returning a set from PL/pgSQL function within an exception handler. Make sure we use the right resource owner when we create the tuplestore to hold returned tuples. Simplify tuplestore API so that the caller doesn't need to be in the right memory context when calling tuplestore_put* functions. tuplestore.c automatically switches to the memory context used when the tuplestore was created. Tuplesort was already modified like this earlier. This patch also removes the now useless MemoryContextSwitch calls from callers. Report by Aleksei on pgsql-bugs on Dec 22 2009. Backpatch to 8.1, like the previous patch that broke this.
2009-12-29 18:40:59 +01:00
if (rsi)
{
estate->tuple_store_cxt = rsi->econtext->ecxt_per_query_memory;
estate->tuple_store_owner = CurrentResourceOwner;
}
else
{
estate->tuple_store_cxt = NULL;
estate->tuple_store_owner = 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->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->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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->eval_econtext = NULL;
estate->cur_expr = NULL;
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;
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->plugin_info = 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.
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
*
* NB: if you change this code, see also the hacks in exec_assign_value's
* PLPGSQL_DTYPE_ARRAYELEM case.
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
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
{
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
Remove dashes in comments that don't need them, rewrap with pgindent.
2001-03-22 07:16:21 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* The grammar can't conveniently set expr->func while building the parse
* tree, so make sure it's set before parser hooks need 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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
expr->func = estate->func;
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
plan = SPI_prepare_params(expr->query,
(ParserSetupHook) plpgsql_parser_setup,
(void *) expr,
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
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:
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
elog(ERROR, "SPI_prepare_params 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);
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);
}
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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
ParamListInfo paramLI;
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
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Set up ParamListInfo (note this is only carrying a hook function, not
* any actual data values, at this point)
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
paramLI = setup_param_list(estate, 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
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
rc = SPI_execute_plan_with_paramlist(expr->plan, paramLI,
estate->readonly_func, tcount);
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
/*
* Check for error, and set FOUND if appropriate (for historical reasons
Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for the case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
2009-01-21 12:02:40 +01:00
* we set FOUND only for certain query types). Also Assert that we
* identified the statement type the same as SPI did.
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
*/
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:
Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for the case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
2009-01-21 12:02:40 +01:00
Assert(!stmt->mod_stmt);
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_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:
Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for the case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
2009-01-21 12:02:40 +01:00
Assert(stmt->mod_stmt);
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_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:
Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for the case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
2009-01-21 12:02:40 +01:00
Assert(!stmt->mod_stmt);
break;
case SPI_OK_REWRITTEN:
Assert(!stmt->mod_stmt);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Add new SPI_OK_REWRITTEN return code to SPI_execute and friends, for the case that the command is rewritten into another type of command. The old behavior to return the command tag of the last executed command was pretty surprising. In PL/pgSQL, for example, it meant that if a command was rewritten to a utility statement, FOUND wasn't set at all.
2009-01-21 12:02:40 +01:00
/*
* The command was rewritten into another kind of command. It's
* not clear what FOUND would mean in that case (and SPI doesn't
* return the row count either), so just set it to false.
*/
exec_set_found(estate, false);
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
break;
Give a more specific error message if you try to COMMIT, ROLLBACK or COPY FROM STDIN in PL/pgSQL. We alread did this for dynamic EXECUTE statements, ie. "EXECUTE 'COMMIT'", but not otherwise.
2010-10-29 10:41:28 +02:00
/* Some SPI errors deserve specific error messages */
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"),
errhint("Use a BEGIN block with an EXCEPTION clause instead.")));
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
default:
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
elog(ERROR, "SPI_execute_plan_with_paramlist 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)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->dno]);
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
else if (stmt->row != NULL)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
row = (PLpgSQL_row *) (estate->datums[stmt->row->dno]);
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
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));
}
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
if (paramLI)
pfree(paramLI);
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
}
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("query string argument of EXECUTE is null")));
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:
Forgot to handle the new SPI_OK_REWRITTEN result code in a couple places.
2009-01-21 12:13:14 +01:00
case SPI_OK_REWRITTEN:
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),
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
errmsg("EXECUTE of SELECT ... INTO is not implemented"),
Add hint suggesting the use of EXECUTE CREATE TABLE ... AS for EXECUTE INTO.
2011-03-16 01:18:35 +01:00
errhint("You might want to use EXECUTE ... INTO or EXECUTE CREATE TABLE ... AS instead.")));
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)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->dno]);
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
else if (stmt->row != NULL)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
row = (PLpgSQL_row *) (estate->datums[stmt->row->dno]);
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
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
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
portal = exec_dynquery_with_params(estate, stmt->query, stmt->params,
NULL, 0);
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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
ParamListInfo paramLI;
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 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 ...
* ----------
*/
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
portal = exec_dynquery_with_params(estate,
stmt->dynquery,
stmt->params,
curname,
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
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
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Set up ParamListInfo (note this is only carrying a hook function, not
* any actual data values, at this point)
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
paramLI = setup_param_list(estate, 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
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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
portal = SPI_cursor_open_with_paramlist(curname, query->plan,
paramLI,
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);
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);
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
if (paramLI)
pfree(paramLI);
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;
Minor code beautification/consolidation.
2009-04-02 22:16:30 +02:00
uint32 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
/* ----------
* 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),
Message wordsmithing
2009-02-18 12:33:04 +01: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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("relative or absolute cursor position is 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_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)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->dno]);
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
else if (stmt->row != NULL)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
row = (PLpgSQL_row *) (estate->datums[stmt->row->dno]);
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
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
/* ----------
Minor code beautification/consolidation.
2009-04-02 22:16:30 +02:00
* Set the target appropriately.
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 (n == 0)
exec_move_row(estate, rec, row, NULL, tuptab->tupdesc);
else
exec_move_row(estate, rec, row, tuptab->vals[0], tuptab->tupdesc);
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
Minor code beautification/consolidation.
2009-04-02 22:16:30 +02:00
/* Set the ROW_COUNT and the global FOUND variable appropriately. */
Have PL/pgSQL FETCH set DIAGNOSTICS ROW_COUNT. Andrew Gierth
2009-04-02 21:20:45 +02:00
estate->eval_processed = n;
Minor code beautification/consolidation.
2009-04-02 22:16:30 +02:00
exec_set_found(estate, n != 0);
Have PL/pgSQL FETCH set DIAGNOSTICS ROW_COUNT. Andrew Gierth
2009-04-02 21:20:45 +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
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),
Message wordsmithing
2009-02-18 12:33:04 +01: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
/* ----------
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
* exec_assign_expr Put an expression's result into a variable.
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_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
}
Add GET STACKED DIAGNOSTICS plpgsql command to retrieve exception info. This is more SQL-spec-compliant, more easily extensible, and better performing than the old method of inventing special variables. Pavel Stehule, reviewed by Shigeru Hanada and David Wheeler
2011-07-18 20:46:27 +02:00
/* ----------
* exec_assign_c_string Put a C string into a text variable.
*
* We take a NULL pointer as signifying empty string, not SQL null.
* ----------
*/
static void
exec_assign_c_string(PLpgSQL_execstate *estate, PLpgSQL_datum *target,
const char *str)
{
text *value;
bool isnull = false;
if (str != NULL)
value = cstring_to_text(str);
else
value = cstring_to_text("");
exec_assign_value(estate, target, PointerGetDatum(value),
TEXTOID, &isnull);
pfree(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
/* ----------
* exec_assign_value Put a value into a target field
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
*
* Note: in some code paths, this may leak memory in the eval_econtext;
* we assume that will be cleaned up later by exec_eval_cleanup. We cannot
* call exec_eval_cleanup here for fear of destroying the input Datum 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 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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("null value cannot be assigned to variable \"%s\" declared NOT NULL",
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
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;
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;
Don't choke when exec_move_row assigns a synthesized null to a column that happens to be composite itself. Per bug #5314 from Oleg Serov. Backpatch to 8.0 --- 7.4 has got too many other shortcomings in composite-type support to make this worth worrying about in that branch.
2010-02-12 20:37:36 +01:00
/* Source must be of RECORD or composite type */
if (!type_is_rowtype(valtype))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot assign non-composite value to a row variable")));
/* Source is a tuple Datum, so safe to do this: */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
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;
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;
Don't choke when exec_move_row assigns a synthesized null to a column that happens to be composite itself. Per bug #5314 from Oleg Serov. Backpatch to 8.0 --- 7.4 has got too many other shortcomings in composite-type support to make this worth worrying about in that branch.
2010-02-12 20:37:36 +01:00
/* Source must be of RECORD or composite type */
if (!type_is_rowtype(valtype))
ereport(ERROR,
(errcode(ERRCODE_DATATYPE_MISMATCH),
errmsg("cannot assign non-composite value to a record variable")));
/* Source is a tuple Datum, so safe to do this: */
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
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
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02: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
{
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
/*
* Target is an element of an array
*/
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
int32 arraytypmod;
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;
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
SPITupleTable *save_eval_tuptable;
/*
* We need to do subscript evaluation, which might require
* evaluating general expressions; and the caller might have
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* done that too in order to prepare the input Datum. We have
* to save and restore the caller's SPI_execute result, if
* any.
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
*/
save_eval_tuptable = estate->eval_tuptable;
estate->eval_tuptable = NULL;
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
/*
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("number of array dimensions (%d) exceeds the maximum allowed (%d)",
Fix wrong error reports in 'number of array dimensions exceeds the maximum allowed' messages, that have reported one-less dimensions. Alexey Klyukin
2011-02-01 07:21:32 +01:00
nsubscripts + 1, MAXDIM)));
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
subscripts[nsubscripts++] = arrayelem->subscript;
target = estate->datums[arrayelem->arrayparentno];
} while (target->dtype == PLPGSQL_DTYPE_ARRAYELEM);
/* Fetch current value of array datum */
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
exec_eval_datum(estate, target,
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
&arraytypeid, &arraytypmod,
&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
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
/* If target is domain over array, reduce to base type */
arraytypeid = getBaseTypeAndTypmod(arraytypeid, &arraytypmod);
/* ... and identify the element type */
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),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("array subscript in assignment must not be null")));
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Clean up in case the subscript expression wasn't
* simple. We can't do exec_eval_cleanup, but we can do
* this much (which is safe because the integer subscript
* value is surely pass-by-value), and we must do it in
* case the next subscript expression isn't simple either.
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
*/
if (estate->eval_tuptable != NULL)
SPI_freetuptable(estate->eval_tuptable);
estate->eval_tuptable = 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
Fix incorrect logic in plpgsql for cleanup after evaluation of non-simple expressions. We need to deal with this when handling subscripts in an array assignment, and also when catching an exception. In an Assert-enabled build these omissions led to Assert failures, but I think in a normal build the only consequence would be short-term memory leakage; which may explain why this wasn't reported from the field long ago. Back-patch to all supported versions. 7.4 doesn't have exceptions, but otherwise these bugs go all the way back. Heikki Linnakangas and Tom Lane
2010-08-09 20:50:11 +02:00
/* Now we can restore caller's SPI_execute result if any. */
Assert(estate->eval_tuptable == NULL);
estate->eval_tuptable = save_eval_tuptable;
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,
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
arraytypmod,
Mop-up for nulls-in-arrays patch: fix some places that access array contents directly.
2005-11-18 03:38:24 +01:00
*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
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
* at this point. Note that if the target is a domain,
* coercing the base array type back up to the domain will
* happen within exec_assign_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 = 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
*
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
* The type oid, typmod, value in Datum format, and null flag are returned.
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
*
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 *typeid,
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
int32 *typetypmod,
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
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
*typetypmod = var->datatype->atttypmod;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*value = var->value;
*isnull = var->isnull;
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
*typetypmod = row->rowtupdesc->tdtypmod;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*value = HeapTupleGetDatum(tup);
*isnull = false;
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
*typetypmod = rec->tupdesc->tdtypmod;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
*value = HeapTupleGetDatum(&worktup);
*isnull = false;
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);
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
/* XXX there's no SPI_gettypmod, for some reason */
if (fno > 0)
*typetypmod = rec->tupdesc->attrs[fno - 1]->atttypmod;
else
*typetypmod = -1;
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
*value = SPI_getbinval(rec->tup, rec->tupdesc, fno, isnull);
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
break;
}
default:
elog(ERROR, "unrecognized dtype: %d", datum->dtype);
}
}
/*
* exec_get_datum_type Get datatype of a PLpgSQL_datum
*
* This is the same logic as in exec_eval_datum, except that it can handle
* some cases where exec_eval_datum has to fail; specifically, we may have
* a tupdesc but no row value for a record variable. (This currently can
* happen only for a trigger's NEW/OLD records.)
*/
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01:00
Oid
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
exec_get_datum_type(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum)
{
Oid typeid;
switch (datum->dtype)
{
case PLPGSQL_DTYPE_VAR:
{
PLpgSQL_var *var = (PLpgSQL_var *) datum;
typeid = var->datatype->typoid;
break;
}
case PLPGSQL_DTYPE_ROW:
{
PLpgSQL_row *row = (PLpgSQL_row *) datum;
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);
typeid = row->rowtupdesc->tdtypeid;
break;
}
case PLPGSQL_DTYPE_REC:
{
PLpgSQL_rec *rec = (PLpgSQL_rec *) datum;
if (rec->tupdesc == NULL)
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
ereport(ERROR,
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01: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.")));
/* Make sure we have a valid type/typmod setting */
BlessTupleDesc(rec->tupdesc);
typeid = rec->tupdesc->tdtypeid;
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
break;
}
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
case PLPGSQL_DTYPE_RECFIELD:
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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
PLpgSQL_recfield *recfield = (PLpgSQL_recfield *) datum;
PLpgSQL_rec *rec;
int fno;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
rec = (PLpgSQL_rec *) (estate->datums[recfield->recparentno]);
if (rec->tupdesc == NULL)
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
ereport(ERROR,
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01: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.")));
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);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
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);
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
typeid = InvalidOid; /* keep compiler quiet */
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
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
}
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
return typeid;
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
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01:00
/*
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
* exec_get_datum_type_info Get datatype etc of a PLpgSQL_datum
*
* An extended version of exec_get_datum_type, which also retrieves the
* typmod and collation of the datum.
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01:00
*/
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
void
exec_get_datum_type_info(PLpgSQL_execstate *estate,
PLpgSQL_datum *datum,
Oid *typeid, int32 *typmod, Oid *collation)
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01:00
{
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
switch (datum->dtype)
{
case PLPGSQL_DTYPE_VAR:
{
PLpgSQL_var *var = (PLpgSQL_var *) datum;
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01:00
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
*typeid = var->datatype->typoid;
*typmod = var->datatype->atttypmod;
*collation = var->datatype->collation;
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
break;
}
case PLPGSQL_DTYPE_ROW:
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
{
PLpgSQL_row *row = (PLpgSQL_row *) datum;
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);
*typeid = row->rowtupdesc->tdtypeid;
/* do NOT return the mutable typmod of a RECORD variable */
*typmod = -1;
/* composite types are never collatable */
*collation = InvalidOid;
break;
}
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
case PLPGSQL_DTYPE_REC:
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
{
PLpgSQL_rec *rec = (PLpgSQL_rec *) datum;
if (rec->tupdesc == NULL)
ereport(ERROR,
(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.")));
/* Make sure we have a valid type/typmod setting */
BlessTupleDesc(rec->tupdesc);
*typeid = rec->tupdesc->tdtypeid;
/* do NOT return the mutable typmod of a RECORD variable */
*typmod = -1;
/* composite types are never collatable */
*collation = InvalidOid;
break;
}
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
case PLPGSQL_DTYPE_RECFIELD:
{
PLpgSQL_recfield *recfield = (PLpgSQL_recfield *) datum;
PLpgSQL_rec *rec;
int fno;
rec = (PLpgSQL_rec *) (estate->datums[recfield->recparentno]);
if (rec->tupdesc == NULL)
ereport(ERROR,
(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.")));
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)));
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
*typeid = SPI_gettypeid(rec->tupdesc, fno);
/* XXX there's no SPI_gettypmod, for some reason */
if (fno > 0)
*typmod = rec->tupdesc->attrs[fno - 1]->atttypmod;
else
*typmod = -1;
/* XXX there's no SPI_getcollation either */
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
if (fno > 0)
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
*collation = rec->tupdesc->attrs[fno - 1]->attcollation;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
else /* no system column types have collation */
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
*collation = InvalidOid;
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
break;
}
default:
elog(ERROR, "unrecognized dtype: %d", datum->dtype);
Pgindent run before 9.1 beta2.
2011-06-09 20:32:50 +02:00
*typeid = InvalidOid; /* keep compiler quiet */
Make plpgsql provide the typmods for its variables to the main parser. Historically we didn't do this, even though we had the information, because plpgsql passed its Params via SPI APIs that only include type OIDs not typmods. Now that plpgsql uses parser callbacks to create Params, it's easy to insert the right typmod. This should generally result in lower surprise factors, because a plpgsql variable that is declared with a typmod will now work more like a table column with the same typmod. In particular it's the "right" way to fix bug #6020, in which plpgsql's attempt to return an anonymous record type is defeated by stricter record-type matching checks that were added in 9.0. However, it's not impossible that this could result in subtle behavioral changes that could break somebody's existing plpgsql code, so I'm afraid to back-patch this change into released branches. In those branches we'll have to lobotomize the record-type checks instead.
2011-05-22 21:13:35 +02:00
*typmod = -1;
*collation = InvalidOid;
Fix collation handling in plpgsql functions. Make plpgsql treat the input collation as a polymorphism variable, so that we cache separate plans for each input collation that's used in a particular session, as per recent discussion. Propagate the input collation to all collatable input parameters. I chose to also propagate the input collation to all declared variables of collatable types, which is a bit more debatable but seems to be necessary for non-astonishing behavior. (Copying a parameter into a separate local variable shouldn't result in a change of behavior, for example.) There is enough infrastructure here to support declaring a collation for each local variable to override that default, but I thought we should wait to see what the field demand is before adding such a feature. In passing, remove exec_get_rec_fieldtype(), which wasn't used anywhere. Documentation patch to follow.
2011-03-25 20:06:36 +01:00
break;
}
Change plpgsql from using textual substitution to insert variable references into SQL expressions, to using the newly added parser callback hooks. This allows us to do the substitutions in a more semantically-aware way: a variable reference will only be recognized where it can validly go, ie, a place where a column value or parameter would be legal, instead of the former behavior that would replace any textual match including table names and column aliases (leading to syntax errors later on). A release-note-worthy fine point is that plpgsql variable names that match fully-reserved words will now need to be quoted. This commit preserves the former behavior that variable references take precedence over any possible match to a column name. The infrastructure is in place to support the reverse precedence or throwing an error on ambiguity, but those behaviors aren't accessible yet. Most of the code changes here are associated with making the namespace data structure persist so that it can be consulted at runtime, instead of throwing it away at the end of initial function parsing. The plpgsql scanner is still doing name lookups, but that behavior is now irrelevant for SQL expressions. A future commit will deal with removing unnecessary lookups.
2009-11-06 19:37:55 +01: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
/*
Fix plpgsql's exec_eval_expr() to ensure it returns a sane type OID even when the expression is a query that returns no rows. So far as I can tell, the only caller that actually fails when a garbage OID is returned is exec_stmt_case(), which is new in 8.4 --- in all other cases, we might make a useless trip through casting logic, but we won't fail since the isnull flag will be set. Hence, backpatch only to 8.4, just in case there are apps out there that aren't expecting an error to be thrown if the query returns more or less than one column. (Which seems unlikely, since the error would be thrown if the query ever did return a row; but it's possible there's some never-exercised code out there.) Per report from Mario Splivalo.
2010-04-15 01:52:10 +02:00
* Check that the expression returns exactly one column...
*/
if (estate->eval_tuptable->tupdesc->natts != 1)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg_plural("query \"%s\" returned %d column",
"query \"%s\" returned %d columns",
estate->eval_tuptable->tupdesc->natts,
expr->query,
estate->eval_tuptable->tupdesc->natts)));
/*
* ... and get the column's datatype.
*/
*rettype = SPI_gettypeid(estate->eval_tuptable->tupdesc, 1);
/*
* If there are no rows selected, the result is a NULL of that 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
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
/*
Fix plpgsql's exec_eval_expr() to ensure it returns a sane type OID even when the expression is a query that returns no rows. So far as I can tell, the only caller that actually fails when a garbage OID is returned is exec_stmt_case(), which is new in 8.4 --- in all other cases, we might make a useless trip through casting logic, but we won't fail since the isnull flag will be set. Hence, backpatch only to 8.4, just in case there are apps out there that aren't expecting an error to be thrown if the query returns more or less than one column. (Which seems unlikely, since the error would be thrown if the query ever did return a row; but it's possible there's some never-exercised code out there.) Per report from Mario Splivalo.
2010-04-15 01:52:10 +02:00
* Check that the expression returned no more than one row.
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +02:00
*/
Fix plpgsql's exec_eval_expr() to ensure it returns a sane type OID even when the expression is a query that returns no rows. So far as I can tell, the only caller that actually fails when a garbage OID is returned is exec_stmt_case(), which is new in 8.4 --- in all other cases, we might make a useless trip through casting logic, but we won't fail since the isnull flag will be set. Hence, backpatch only to 8.4, just in case there are apps out there that aren't expecting an error to be thrown if the query returns more or less than one column. (Which seems unlikely, since the error would be thrown if the query ever did return a row; but it's possible there's some never-exercised code out there.) Per report from Mario Splivalo.
2010-04-15 01:52:10 +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)));
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 plpgsql's exec_eval_expr() to ensure it returns a sane type OID even when the expression is a query that returns no rows. So far as I can tell, the only caller that actually fails when a garbage OID is returned is exec_stmt_case(), which is new in 8.4 --- in all other cases, we might make a useless trip through casting logic, but we won't fail since the isnull flag will be set. Hence, backpatch only to 8.4, just in case there are apps out there that aren't expecting an error to be thrown if the query returns more or less than one column. (Which seems unlikely, since the error would be thrown if the query ever did return a row; but it's possible there's some never-exercised code out there.) Per report from Mario Splivalo.
2010-04-15 01:52:10 +02:00
* Return the single result Datum.
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
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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
ParamListInfo paramLI;
OK, folks, here is the pgindent output.
1998-09-01 06:40:42 +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
/*
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
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Set up ParamListInfo (note this is only carrying a hook function, not
* any actual data values, at this point)
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 support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
paramLI = setup_param_list(estate, 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
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)
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*portalP = SPI_cursor_open_with_paramlist(NULL, expr->plan,
paramLI,
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));
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
if (paramLI)
pfree(paramLI);
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 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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
rc = SPI_execute_plan_with_paramlist(expr->plan, paramLI,
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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
if (paramLI)
pfree(paramLI);
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
}
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)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
rec = (PLpgSQL_rec *) (estate->datums[stmt->rec->dno]);
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
else if (stmt->row != NULL)
Rename several aliases for PLpgSQL_datum.dno to also be called dno. Hopefully this will forestall future confusion about their roles. Jonah Harris
2008-11-05 01:07:54 +01:00
row = (PLpgSQL_row *) (estate->datums[stmt->row->dno]);
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
else
elog(ERROR, "unsupported target");
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane pointed out. The bug affects FOR statement variants too, because you can close an implicitly created cursor too by guessing the "<unnamed portal X>" name created for it. To fix that, "pin" the portal to prevent it from being dropped while it's being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is the oldest supported version.
2010-07-05 11:27:18 +02:00
/*
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
* Make sure the portal doesn't get closed by the user statements we
* execute.
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane pointed out. The bug affects FOR statement variants too, because you can close an implicitly created cursor too by guessing the "<unnamed portal X>" name created for it. To fix that, "pin" the portal to prevent it from being dropped while it's being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is the oldest supported version.
2010-07-05 11:27:18 +02:00
*/
PinPortal(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
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Fetch the initial tuple(s). If prefetching is allowed then we grab a
* few more rows to avoid multiple trips through executor startup
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
* overhead.
*/
SPI_cursor_fetch(portal, true, prefetch_ok ? 10 : 1);
tuptab = SPI_tuptable;
n = SPI_processed;
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* If the query didn't return any rows, set the target to NULL and fall
* through with found = false.
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 (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.
*/
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane pointed out. The bug affects FOR statement variants too, because you can close an implicitly created cursor too by guessing the "<unnamed portal X>" name created for it. To fix that, "pin" the portal to prevent it from being dropped while it's being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is the oldest supported version.
2010-07-05 11:27:18 +02:00
SPI_cursor_fetch(portal, true, prefetch_ok ? 50 : 1);
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
tuptab = SPI_tuptable;
n = SPI_processed;
}
loop_exit:
/*
* Release last group of tuples (if any)
*/
SPI_freetuptable(tuptab);
The previous fix in CVS HEAD and 8.4 for handling the case where a cursor being used in a PL/pgSQL FOR loop is closed was inadequate, as Tom Lane pointed out. The bug affects FOR statement variants too, because you can close an implicitly created cursor too by guessing the "<unnamed portal X>" name created for it. To fix that, "pin" the portal to prevent it from being dropped while it's being used in a PL/pgSQL FOR loop. Backpatch all the way to 7.4 which is the oldest supported version.
2010-07-05 11:27:18 +02:00
UnpinPortal(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
/*
* 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
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
* TRUE. If the expression cannot be handled by simple evaluation,
* return FALSE.
*
* Because we only store one execution tree for a simple expression, we
* can't handle recursion cases. So, if we see the tree is already busy
* with an evaluation in the current xact, we just return FALSE and let the
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* caller run the expression the hard way. (Other alternatives such as
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
* creating a new tree for a recursive call either introduce memory leaks,
* or add enough bookkeeping to be doubtful wins anyway.) Another case that
* is covered by the expr_simple_in_use test is where a previous execution
* of the tree was aborted by an error: the tree may contain bogus state
* so we dare not re-use 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
*
* 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;
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
LocalTransactionId curlxid = MyProc->lxid;
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;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
PLpgSQL_expr *save_cur_expr;
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;
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
/*
* If expression is in use in current xact, don't touch it.
*/
if (expr->expr_simple_in_use && expr->expr_simple_lxid == curlxid)
return 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
/*
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
* the current transaction. (This will be forced to happen if we called
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
* 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 the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
if (expr->expr_simple_lxid != curlxid)
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
{
Save a few cycles in plpgsql simple-expression initialization. Instead of using ExecPrepareExpr, call ExecInitExpr. The net change here is that we don't apply expression_planner() to the expression tree. There is no need to do so, because that tree is extracted from a fully planned plancache entry, so all the needed work is already done. This reduces the setup costs by about a factor of 2 according to some simple tests. Oversight noted while fooling around with the simple-expression code for previous fix.
2010-10-28 19:29:13 +02:00
oldcontext = MemoryContextSwitchTo(simple_eval_estate->es_query_cxt);
expr->expr_simple_state = ExecInitExpr(expr->expr_simple_expr, NULL);
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
expr->expr_simple_in_use = false;
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
expr->expr_simple_lxid = curlxid;
Save a few cycles in plpgsql simple-expression initialization. Instead of using ExecPrepareExpr, call ExecInitExpr. The net change here is that we don't apply expression_planner() to the expression tree. There is no need to do so, because that tree is extracted from a fully planned plancache entry, so all the needed work is already done. This reduces the setup costs by about a factor of 2 according to some simple tests. Oversight noted while fooling around with the simple-expression code for previous fix.
2010-10-28 19:29:13 +02:00
MemoryContextSwitchTo(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
}
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Create the param list in econtext's temporary memory context. We won't
* need to free it explicitly, since it will go away at the next reset of
* that context.
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*
* XXX think about avoiding repeated palloc's for param lists? It should
* be possible --- this routine isn't re-entrant anymore.
*
* Just for paranoia's sake, save and restore the prior value of
* estate->cur_expr, which setup_param_list() sets.
*/
save_cur_expr = estate->cur_expr;
paramLI = setup_param_list(estate, expr);
econtext->ecxt_param_list_info = paramLI;
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
/*
* Mark expression as busy for the duration of the ExecEvalExpr call.
*/
expr->expr_simple_in_use = true;
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);
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/* Assorted cleanup */
Fix plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
expr->expr_simple_in_use = false;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
estate->cur_expr = save_cur_expr;
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
MemoryContextSwitchTo(oldcontext);
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
/*
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
* Create a ParamListInfo to pass to SPI
*
* The ParamListInfo array is initially all zeroes, in particular the
* ptype values are all InvalidOid. This causes the executor to call the
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* paramFetch hook each time it wants a value. We thus evaluate only the
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
* parameters actually demanded.
*
* The result is a locally palloc'd array that should be pfree'd after use;
* but note it can be 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
*/
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
static ParamListInfo
setup_param_list(PLpgSQL_execstate *estate, PLpgSQL_expr *expr)
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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
ParamListInfo paramLI;
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
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Could we re-use these arrays instead of palloc'ing a new one each time?
* However, we'd have to zero the array each time anyway, since new values
* might have been assigned to the variables.
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*/
if (estate->ndatums > 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
{
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/* sizeof(ParamListInfoData) includes the first array element */
paramLI = (ParamListInfo)
palloc0(sizeof(ParamListInfoData) +
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
(estate->ndatums - 1) * sizeof(ParamExternData));
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
paramLI->paramFetch = plpgsql_param_fetch;
paramLI->paramFetchArg = (void *) estate;
paramLI->parserSetup = (ParserSetupHook) plpgsql_parser_setup;
paramLI->parserSetupArg = (void *) expr;
paramLI->numParams = estate->ndatums;
/*
* Set up link to active expr where the hook functions can find it.
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Callers must save and restore cur_expr if there is any chance that
* they are interrupting an active use of parameters.
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*/
estate->cur_expr = expr;
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Also make sure this is set before parser hooks need it. There is
* no need to save and restore, since the value is always correct once
* set.
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*/
expr->func = estate->func;
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
}
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
else
paramLI = NULL;
return paramLI;
}
/*
* plpgsql_param_fetch paramFetch callback for dynamic parameter fetch
*/
static void
plpgsql_param_fetch(ParamListInfo params, int paramid)
{
int dno;
PLpgSQL_execstate *estate;
PLpgSQL_expr *expr;
PLpgSQL_datum *datum;
ParamExternData *prm;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
int32 prmtypmod;
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
/* paramid's are 1-based, but dnos are 0-based */
dno = paramid - 1;
Assert(dno >= 0 && dno < params->numParams);
/* fetch back the hook data */
estate = (PLpgSQL_execstate *) params->paramFetchArg;
expr = estate->cur_expr;
Assert(params->numParams == estate->ndatums);
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* Do nothing if asked for a value that's not supposed to be used by this
* SQL expression. This avoids unwanted evaluations when functions such
* as copyParamList try to materialize all the values.
Add support for invoking parser callback hooks via SPI and in cached plans. As proof of concept, modify plpgsql to use the hooks. plpgsql is still inserting $n symbols textually, but the "back end" of the parsing process now goes through the ParamRef hook instead of using a fixed parameter-type array, and then execution only fetches actually-referenced parameters, using a hook added to ParamListInfo. Although there's a lot left to be done in plpgsql, this already cures the "if (TG_OP = 'INSERT' and NEW.foo ...)" problem, as illustrated by the changed regression test.
2009-11-04 23:26:08 +01:00
*/
if (!bms_is_member(dno, expr->paramnos))
return;
/* OK, evaluate the value and store into the appropriate paramlist slot */
datum = estate->datums[dno];
prm = &params->params[dno];
exec_eval_datum(estate, datum,
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
&prm->ptype, &prmtypmod,
&prm->value, &prm->isnull);
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
}
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 ==
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* HeapTupleHeaderGetNatts(tup->t_data), but that's wrong. The tuple
* might 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;
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Don't choke when exec_move_row assigns a synthesized null to a column that happens to be composite itself. Per bug #5314 from Oleg Serov. Backpatch to 8.0 --- 7.4 has got too many other shortcomings in composite-type support to make this worth worrying about in that branch.
2010-02-12 20:37:36 +01:00
/*
* InvalidOid is OK because exec_assign_value doesn't care
* about the type of a source NULL
*/
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
int32 fieldtypmod;
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]],
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
&fieldtypeid, &fieldtypmod,
&dvalues[i], &nulls[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
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;
Improve handling of domains over arrays. This patch eliminates various bizarre behaviors caused by sloppy thinking about the difference between a domain type and its underlying array type. In particular, the operation of updating one element of such an array has to be considered as yielding a value of the underlying array type, *not* a value of the domain, because there's no assurance that the domain's CHECK constraints are still satisfied. If we're intending to store the result back into a domain column, we have to re-cast to the domain type so that constraints are re-checked. For similar reasons, such a domain can't be blindly matched to an ANYARRAY polymorphic parameter, because the polymorphic function is likely to apply array-ish operations that could invalidate the domain constraints. For the moment, we just forbid such matching. We might later wish to insert an automatic downcast to the underlying array type, but such a change should also change matching of domains to ANYELEMENT for consistency. To ensure that all such logic is rechecked, this patch removes the original hack of setting a domain's pg_type.typelem field to match its base type; the typelem will always be zero instead. In those places where it's really okay to look through the domain type with no other logic changes, use the newly added get_base_element_type function in place of get_element_type. catversion bumped due to change in pg_type contents. Per bug #5717 from Richard Huxton and subsequent discussion.
2010-10-21 22:07:17 +02:00
/* XXX should we insist on typmod match, too? */
Make the world safe (more or less) for dropped columns in plpgsql rowtypes.
2003-09-26 01:02:12 +02:00
}
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)
{
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);
Insert conditional SPI_push/SPI_pop calls into InputFunctionCall, OutputFunctionCall, and friends. This allows SPI-using functions to invoke datatype I/O without concern for the possibility that a SPI-using function will be called (which could be either the I/O function itself, or a function used in a domain check constraint). It's a tad ugly, but not nearly as ugly as what'd be needed to make this work via retail insertion of push/pop operations in all the PLs. This reverts my patch of 2007-01-30 that inserted some retail SPI_push/pop calls into plpgsql; that approach only fixed plpgsql, and not any other PLs. But the other PLs have the issue too, as illustrated by a recent gripe from Christian Schröder. Back-patch to 8.2, which is as far back as this solution will work. It's also as far back as we need to worry about the domain-constraint case, since earlier versions did not attempt to check domain constraints within datatype input. I'm not aware of any old I/O functions that use SPI themselves, so this should be sufficient for a back-patch.
2009-01-07 21:38:56 +01:00
return OidOutputFunctionCall(typoutput, value);
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);
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);
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
{
value = InputFunctionCall(reqinput, NULL,
reqtypioparam, reqtypmod);
}
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
{
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass casting effort whenever the input value was NULL. However this prevents application of not-null domain constraints in the cases that use this function, as illustrated in bug #4741. Since this function isn't meant for use in performance-critical paths anyway, this certainly seems like another case of "premature optimization is the root of all evil". Back-patch as far as 8.2; older versions made no effort to enforce domain constraints here anyway.
2009-04-02 03:16:11 +02:00
if (valtype != reqtype || reqtypmod != -1)
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
{
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass casting effort whenever the input value was NULL. However this prevents application of not-null domain constraints in the cases that use this function, as illustrated in bug #4741. Since this function isn't meant for use in performance-critical paths anyway, this certainly seems like another case of "premature optimization is the root of all evil". Back-patch as far as 8.2; older versions made no effort to enforce domain constraints here anyway.
2009-04-02 03:16:11 +02:00
Oid typinput;
Oid typioparam;
FmgrInfo 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
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass casting effort whenever the input value was NULL. However this prevents application of not-null domain constraints in the cases that use this function, as illustrated in bug #4741. Since this function isn't meant for use in performance-critical paths anyway, this certainly seems like another case of "premature optimization is the root of all evil". Back-patch as far as 8.2; older versions made no effort to enforce domain constraints here anyway.
2009-04-02 03:16:11 +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
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass casting effort whenever the input value was NULL. However this prevents application of not-null domain constraints in the cases that use this function, as illustrated in bug #4741. Since this function isn't meant for use in performance-critical paths anyway, this certainly seems like another case of "premature optimization is the root of all evil". Back-patch as far as 8.2; older versions made no effort to enforce domain constraints here anyway.
2009-04-02 03:16:11 +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
plpgsql's exec_simple_cast_value() mistakenly supposed that it could bypass casting effort whenever the input value was NULL. However this prevents application of not-null domain constraints in the cases that use this function, as illustrated in bug #4741. Since this function isn't meant for use in performance-critical paths anyway, this certainly seems like another case of "premature optimization is the root of all evil". Back-patch as far as 8.2; older versions made no effort to enforce domain constraints here anyway.
2009-04-02 03:16:11 +02:00
value = exec_cast_value(value,
valtype,
reqtype,
&finfo_input,
typioparam,
reqtypmod,
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
}
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;
}
Revise collation derivation method and expression-tree representation. All expression nodes now have an explicit output-collation field, unless they are known to only return a noncollatable data type (such as boolean or record). Also, nodes that can invoke collation-aware functions store a separate field that is the collation value to pass to the function. This avoids confusion that arises when a function has collatable inputs and noncollatable output type, or vice versa. Also, replace the parser's on-the-fly collation assignment method with a post-pass over the completed expression tree. This allows us to use a more complex (and hopefully more nearly spec-compliant) assignment rule without paying for it in extra storage in every expression node. Fix assorted bugs in the planner's handling of collations by making collation one of the defining properties of an EquivalenceClass and by converting CollateExprs into discardable RelabelType nodes during expression preprocessing.
2011-03-20 01:29:08 +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;
}
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;
}
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;
Keep exec_simple_check_plan() from thinking "SELECT foo INTO bar" is simple. It's not clear if this situation can occur in plpgsql other than via the EXECUTE USING case Heikki illustrated, which I will shortly close off. However, ignoring the intoClause if it's there is surely wrong, so let's patch it for safety. Backpatch to 8.3, which is as far back as this code has a PlannedStmt to deal with. There might be another way to make an equivalent test before that, but since this is just preventing hypothetical bugs, I'm not going to obsess about it.
2010-08-19 20:10:48 +02:00
if (stmt->commandType != CMD_SELECT || stmt->intoClause)
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 plpgsql's handling of "simple" expression evaluation. In general, expression execution state trees aren't re-entrantly usable, since functions can store private state information in them. For efficiency reasons, plpgsql tries to cache and reuse state trees for "simple" expressions. It can get away with that most of the time, but it can fail if the state tree is dirty from a previous failed execution (as in an example from Alvaro) or is being used recursively (as noted by me). Fix by tracking whether a state tree is in use, and falling back to the "non-simple" code path if so. This results in a pretty considerable speed hit when the non-simple path is taken, but the available alternatives seem even more unpleasant because they add overhead in the simple path. Per idea from Heikki. Back-patch to all supported branches.
2010-10-28 19:00:54 +02:00
expr->expr_simple_in_use = false;
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
expr->expr_simple_lxid = InvalidLocalTransactionId;
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
}
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
*
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
* We may need to create a new simple_eval_estate too, if there's not one
* already for the current transaction. The EState will be cleaned up at
* transaction end.
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)
{
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
SimpleEcontextStackEntry *entry;
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
/*
* Create an EState for evaluation of simple expressions, if there's not
* one already in the current transaction. The EState is made a child of
* TopTransactionContext so it will have the right lifespan.
*/
if (simple_eval_estate == 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
{
MemoryContext oldcontext;
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
oldcontext = MemoryContextSwitchTo(TopTransactionContext);
simple_eval_estate = CreateExecutorState();
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
MemoryContextSwitchTo(oldcontext);
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
/*
* Create a child econtext for the current function.
*/
estate->eval_econtext = CreateExprContext(simple_eval_estate);
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
/*
* Make a stack entry so we can clean up the econtext at subxact end.
* Stack entries are kept in TopTransactionContext for simplicity.
*/
entry = (SimpleEcontextStackEntry *)
MemoryContextAlloc(TopTransactionContext,
sizeof(SimpleEcontextStackEntry));
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
entry->stack_econtext = estate->eval_econtext;
entry->xact_subxid = GetCurrentSubTransactionId();
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
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
entry->next = simple_econtext_stack;
simple_econtext_stack = entry;
}
/*
* plpgsql_destroy_econtext --- destroy function's econtext
*
* We check that it matches the top stack entry, and destroy the stack
* entry along with the context.
*/
static void
plpgsql_destroy_econtext(PLpgSQL_execstate *estate)
{
SimpleEcontextStackEntry *next;
Assert(simple_econtext_stack != NULL);
Assert(simple_econtext_stack->stack_econtext == estate->eval_econtext);
next = simple_econtext_stack->next;
pfree(simple_econtext_stack);
simple_econtext_stack = next;
Fix error cleanup failure caused by 8.4 changes in plpgsql to try to avoid memory leakage in error recovery. We were calling FreeExprContext, and therefore invoking ExprContextCallback callbacks, in both normal and error exits from subtransactions. However this isn't very safe, as shown in recent trouble report from Frank van Vugt, in which releasing a tupledesc refcount failed. It's also unnecessary, since the resources that callbacks might wish to release should be cleaned up by other error recovery mechanisms (ie the resource owners). We only really want FreeExprContext to release memory attached to the exprcontext in the error-exit case. So, add a bool parameter to FreeExprContext to tell it not to call the callbacks. A more general solution would be to pass the isCommit bool parameter on to the callbacks, so they could do only safe things during error exit. But that would make the patch significantly more invasive and possibly break third-party code that registers ExprContextCallback callbacks. We might want to do that later in HEAD, but for now I'll just do what seems reasonable to back-patch.
2009-07-18 21:15:42 +02:00
FreeExprContext(estate->eval_econtext, true);
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
estate->eval_econtext = 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
}
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 the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
* interest.
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)
{
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
/* Shouldn't be any econtext stack entries left at commit */
Assert(simple_econtext_stack == NULL);
if (simple_eval_estate)
FreeExecutorState(simple_eval_estate);
simple_eval_estate = 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
}
else
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
{
simple_econtext_stack = NULL;
simple_eval_estate = 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
}
/*
* plpgsql_subxact_cb --- post-subtransaction-commit-or-abort cleanup
*
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
* Make sure any simple-expression econtexts created in the current
* subtransaction get cleaned up. We have to do this explicitly because
* no other code knows which child econtexts of simple_eval_estate belong
* to which level of subxact.
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
*/
void
plpgsql_subxact_cb(SubXactEvent event, SubTransactionId mySubid,
SubTransactionId parentSubid, void *arg)
{
if (event == SUBXACT_EVENT_START_SUB)
return;
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
while (simple_econtext_stack != NULL &&
simple_econtext_stack->xact_subxid == mySubid)
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
{
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
SimpleEcontextStackEntry *next;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Fix error cleanup failure caused by 8.4 changes in plpgsql to try to avoid memory leakage in error recovery. We were calling FreeExprContext, and therefore invoking ExprContextCallback callbacks, in both normal and error exits from subtransactions. However this isn't very safe, as shown in recent trouble report from Frank van Vugt, in which releasing a tupledesc refcount failed. It's also unnecessary, since the resources that callbacks might wish to release should be cleaned up by other error recovery mechanisms (ie the resource owners). We only really want FreeExprContext to release memory attached to the exprcontext in the error-exit case. So, add a bool parameter to FreeExprContext to tell it not to call the callbacks. A more general solution would be to pass the isCommit bool parameter on to the callbacks, so they could do only safe things during error exit. But that would make the patch significantly more invasive and possibly break third-party code that registers ExprContextCallback callbacks. We might want to do that later in HEAD, but for now I'll just do what seems reasonable to back-patch.
2009-07-18 21:15:42 +02:00
FreeExprContext(simple_econtext_stack->stack_econtext,
(event == SUBXACT_EVENT_COMMIT_SUB));
Fix the plpgsql memory leak exhibited in bug #4677. That leak was introduced by my patch of 2007-01-28 to use per-subtransaction ExprContexts/EStates: since we re-prepared any expression tree when the current subtransaction ID changed, we'd accumulate more and more leaked expression state trees in the outermost subtransaction if the same function was executed at multiple levels of subtransaction nesting. To fix, go back to the previous scheme where there was only one EState per transaction for simple plpgsql expressions. We really only need an ExprContext per subtransaction, not a whole EState, so it's possible to keep prepared expression state trees in the one EState throughout the transaction. This should be more efficient as well as not leaking memory for cases involving lots of subtransactions. The added regression test is the case that inspired the 2007-01-28 patch in the first place, just to make sure we didn't go backwards. The current memory leak complaint is unfortunately hard to test for in the regression test framework, though manual testing shows it's fixed. Although this is a pre-existing bug, I'm not back-patching because I'd like to see this method get some field testing first. Consider back-patching if it gets through 8.4beta unscathed.
2009-04-09 04:57:53 +02:00
next = simple_econtext_stack->next;
pfree(simple_econtext_stack);
simple_econtext_stack = next;
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
}
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);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
bool isnull;
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
ppd->values[i] = exec_eval_expr(estate, param,
&isnull,
&ppd->types[i]);
ppd->nulls[i] = isnull ? 'n' : ' ';
ppd->freevals[i] = false;
Revert patch to coerce 'unknown' type parameters in the backend. As Tom pointed out, it would need a 2nd pass after the whole query is processed to correctly check that an unknown Param is coerced to the same target type everywhere. Adding the 2nd pass would add a lot more code, which doesn't seem worth the risk given that there isn't much of a use case for passing unknown Params in the first place. The code would work without that check, but it might be confusing and the behavior would be different from the varparams case. Instead, just coerce all unknown params in a PL/pgSQL USING clause to text. That's simple, and is usually what users expect. Revert the patch in CVS HEAD and master, and backpatch the new solution to 8.4. Unlike the previous solution, this applies easily to 8.4 too.
2010-08-19 18:54:43 +02:00
if (ppd->types[i] == UNKNOWNOID)
{
/*
Be a bit less cavalier with both the code and the comment for UNKNOWN fix.
2010-08-19 19:31:43 +02:00
* Treat 'unknown' parameters as text, since that's what most
* people would expect. SPI_execute_with_args can coerce unknown
* constants in a more intelligent way, but not unknown Params.
* This code also takes care of copying into the right context.
* Note we assume 'unknown' has the representation of C-string.
Revert patch to coerce 'unknown' type parameters in the backend. As Tom pointed out, it would need a 2nd pass after the whole query is processed to correctly check that an unknown Param is coerced to the same target type everywhere. Adding the 2nd pass would add a lot more code, which doesn't seem worth the risk given that there isn't much of a use case for passing unknown Params in the first place. The code would work without that check, but it might be confusing and the behavior would be different from the varparams case. Instead, just coerce all unknown params in a PL/pgSQL USING clause to text. That's simple, and is usually what users expect. Revert the patch in CVS HEAD and master, and backpatch the new solution to 8.4. Unlike the previous solution, this applies easily to 8.4 too.
2010-08-19 18:54:43 +02:00
*/
ppd->types[i] = TEXTOID;
if (!isnull)
{
Be a bit less cavalier with both the code and the comment for UNKNOWN fix.
2010-08-19 19:31:43 +02:00
ppd->values[i] = CStringGetTextDatum(DatumGetCString(ppd->values[i]));
Revert patch to coerce 'unknown' type parameters in the backend. As Tom pointed out, it would need a 2nd pass after the whole query is processed to correctly check that an unknown Param is coerced to the same target type everywhere. Adding the 2nd pass would add a lot more code, which doesn't seem worth the risk given that there isn't much of a use case for passing unknown Params in the first place. The code would work without that check, but it might be confusing and the behavior would be different from the varparams case. Instead, just coerce all unknown params in a PL/pgSQL USING clause to text. That's simple, and is usually what users expect. Revert the patch in CVS HEAD and master, and backpatch the new solution to 8.4. Unlike the previous solution, this applies easily to 8.4 too.
2010-08-19 18:54:43 +02:00
ppd->freevals[i] = true;
}
}
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
/* pass-by-ref non null values must be copied into plpgsql context */
Revert patch to coerce 'unknown' type parameters in the backend. As Tom pointed out, it would need a 2nd pass after the whole query is processed to correctly check that an unknown Param is coerced to the same target type everywhere. Adding the 2nd pass would add a lot more code, which doesn't seem worth the risk given that there isn't much of a use case for passing unknown Params in the first place. The code would work without that check, but it might be confusing and the behavior would be different from the varparams case. Instead, just coerce all unknown params in a PL/pgSQL USING clause to text. That's simple, and is usually what users expect. Revert the patch in CVS HEAD and master, and backpatch the new solution to 8.4. Unlike the previous solution, this applies easily to 8.4 too.
2010-08-19 18:54:43 +02:00
else if (!isnull)
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
int16 typLen;
bool typByVal;
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
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)
{
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
int i;
Support EXECUTE USING in plpgsql. Pavel Stehule, with some improvements by myself.
2008-04-01 05:51:09 +02:00
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
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
exec_dynquery_with_params(PLpgSQL_execstate *estate,
PLpgSQL_expr *dynquery,
List *params,
const char *portalname,
int cursorOptions)
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
{
Portal portal;
Datum query;
bool isnull;
Oid restype;
char *querystr;
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Evaluate the string expression after the EXECUTE keyword. Its result is
* the querystring we have to execute.
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
*/
query = exec_eval_expr(estate, dynquery, &isnull, &restype);
if (isnull)
ereport(ERROR,
(errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
Message wordsmithing
2009-02-18 12:33:04 +01:00
errmsg("query string argument of EXECUTE is null")));
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
/* Get the C-String representation */
querystr = convert_value_to_string(query, restype);
exec_eval_cleanup(estate);
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* 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.
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
*/
if (params)
{
PreparedParamsData *ppd;
ppd = exec_eval_using_params(estate, params);
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
portal = SPI_cursor_open_with_args(portalname,
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
querystr,
ppd->nargs, ppd->types,
ppd->values, ppd->nulls,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
estate->readonly_func,
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
cursorOptions);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
free_params_data(ppd);
}
else
{
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
portal = SPI_cursor_open_with_args(portalname,
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
querystr,
0, NULL,
NULL, NULL,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
estate->readonly_func,
Add "USING expressions" option to plpgsql's OPEN cursor FOR EXECUTE. This is the last EXECUTE-like plpgsql statement that was missing the capability of inserting parameter values via USING. Pavel Stehule, reviewed by Itagaki Takahiro
2010-01-19 02:35:31 +01:00
cursorOptions);
Support RETURN QUERY EXECUTE in plpgsql. Pavel Stehule
2008-05-03 02:11:36 +02:00
}
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;
}