1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* params.h
|
2006-04-22 03:26:01 +02:00
|
|
|
* Support for finding the values associated with Param nodes.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*
|
2021-01-02 19:06:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2021, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/nodes/params.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef PARAMS_H
|
|
|
|
|
#define PARAMS_H
|
|
|
|
|
|
Fix problems with ParamListInfo serialization mechanism.
Commit d1b7c1ffe72e86932b5395f29e006c3f503bc53d introduced a mechanism
for serializing a ParamListInfo structure to be passed to a parallel
worker. However, this mechanism failed to handle external expanded
values, as pointed out by Noah Misch. Repair.
Moreover, plpgsql_param_fetch requires adjustment because the
serialization mechanism needs it to skip evaluating unused parameters
just as we would do when it is called from copyParamList, but params
== estate->paramLI in that case. To fix, make the bms_is_member test
in that function unconditional.
Finally, have setup_param_list set a new ParamListInfo field,
paramMask, to the parameters actually used in the expression, so that
we don't try to fetch those that are not needed when serializing a
parameter list. This isn't necessary for correctness, but it makes
the performance of the parallel executor code comparable to what we
do for cases involving cursors.
Design suggestions and extensive review by Noah Misch. Patch by me.
2015-11-03 00:11:29 +01:00
|
|
|
/* Forward declarations, to avoid including other headers */
|
|
|
|
|
struct Bitmapset;
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
struct ExprState;
|
|
|
|
|
struct Param;
|
2009-11-04 23:26:08 +01:00
|
|
|
struct ParseState;
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
/*
|
1996-08-28 03:59:28 +02:00
|
|
|
* ParamListInfo
|
|
|
|
|
*
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
* ParamListInfo structures are used to pass parameters into the executor
|
|
|
|
|
* for parameterized plans. We support two basic approaches to supplying
|
|
|
|
|
* parameter values, the "static" way and the "dynamic" way.
|
|
|
|
|
*
|
|
|
|
|
* In the static approach, per-parameter data is stored in an array of
|
|
|
|
|
* ParamExternData structs appended to the ParamListInfo struct.
|
|
|
|
|
* Each entry in the array defines the value to be substituted for a
|
|
|
|
|
* PARAM_EXTERN parameter. The "paramid" of a PARAM_EXTERN Param
|
|
|
|
|
* can range from 1 to numParams.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2006-04-22 03:26:01 +02:00
|
|
|
* Although parameter numbers are normally consecutive, we allow
|
|
|
|
|
* ptype == InvalidOid to signal an unused array entry.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2009-11-04 23:26:08 +01:00
|
|
|
* pflags is a flags field. Currently the only used bit is:
|
2006-09-06 22:40:48 +02:00
|
|
|
* PARAM_FLAG_CONST signals the planner that it may treat this parameter
|
|
|
|
|
* as a constant (i.e., generate a plan that works only for this value
|
|
|
|
|
* of the parameter).
|
|
|
|
|
*
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
* In the dynamic approach, all access to parameter values is done through
|
|
|
|
|
* hook functions found in the ParamListInfo struct. In this case,
|
|
|
|
|
* the ParamExternData array is typically unused and not allocated;
|
|
|
|
|
* but the legal range of paramid is still 1 to numParams.
|
|
|
|
|
*
|
2006-04-22 03:26:01 +02:00
|
|
|
* Although the data structure is really an array, not a list, we keep
|
|
|
|
|
* the old typedef name to avoid unnecessary code changes.
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
*
|
|
|
|
|
* There are 3 hook functions that can be associated with a ParamListInfo
|
|
|
|
|
* structure:
|
|
|
|
|
*
|
|
|
|
|
* If paramFetch isn't null, it is called to fetch the ParamExternData
|
|
|
|
|
* for a particular param ID, rather than accessing the relevant element
|
|
|
|
|
* of the ParamExternData array. This supports the case where the array
|
|
|
|
|
* isn't there at all, as well as cases where the data in the array
|
|
|
|
|
* might be obsolete or lazily evaluated. paramFetch must return the
|
|
|
|
|
* address of a ParamExternData struct describing the specified param ID;
|
|
|
|
|
* the convention above about ptype == InvalidOid signaling an invalid
|
|
|
|
|
* param ID still applies. The returned struct can either be placed in
|
|
|
|
|
* the "workspace" supplied by the caller, or it can be in storage
|
|
|
|
|
* controlled by the paramFetch hook if that's more convenient.
|
|
|
|
|
* (In either case, the struct is not expected to be long-lived.)
|
|
|
|
|
* If "speculative" is true, the paramFetch hook should not risk errors
|
|
|
|
|
* in trying to fetch the parameter value, and should report an invalid
|
|
|
|
|
* parameter instead.
|
|
|
|
|
*
|
|
|
|
|
* If paramCompile isn't null, then it controls what execExpr.c compiles
|
|
|
|
|
* for PARAM_EXTERN Param nodes --- typically, this hook would emit a
|
|
|
|
|
* EEOP_PARAM_CALLBACK step. This allows unnecessary work to be
|
|
|
|
|
* optimized away in compiled expressions.
|
|
|
|
|
*
|
|
|
|
|
* If parserSetup isn't null, then it is called to re-instantiate the
|
|
|
|
|
* original parsing hooks when a query needs to be re-parsed/planned.
|
|
|
|
|
* This is especially useful if the types of parameters might change
|
|
|
|
|
* from time to time, since it can replace the need to supply a fixed
|
|
|
|
|
* list of parameter types to the parser.
|
|
|
|
|
*
|
|
|
|
|
* Notice that the paramFetch and paramCompile hooks are actually passed
|
|
|
|
|
* the ParamListInfo struct's address; they can therefore access all
|
|
|
|
|
* three of the "arg" fields, and the distinction between paramFetchArg
|
|
|
|
|
* and paramCompileArg is rather arbitrary.
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
|
|
|
|
|
2006-09-06 22:40:48 +02:00
|
|
|
#define PARAM_FLAG_CONST 0x0001 /* parameter is constant */
|
|
|
|
|
|
2006-04-22 03:26:01 +02:00
|
|
|
typedef struct ParamExternData
|
|
|
|
|
{
|
|
|
|
|
Datum value; /* parameter value */
|
|
|
|
|
bool isnull; /* is it NULL? */
|
2006-09-06 22:40:48 +02:00
|
|
|
uint16 pflags; /* flag bits, see above */
|
2006-04-22 03:26:01 +02:00
|
|
|
Oid ptype; /* parameter's datatype, or 0 */
|
|
|
|
|
} ParamExternData;
|
|
|
|
|
|
2009-11-04 23:26:08 +01:00
|
|
|
typedef struct ParamListInfoData *ParamListInfo;
|
|
|
|
|
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
typedef ParamExternData *(*ParamFetchHook) (ParamListInfo params,
|
|
|
|
|
int paramid, bool speculative,
|
|
|
|
|
ParamExternData *workspace);
|
|
|
|
|
|
|
|
|
|
typedef void (*ParamCompileHook) (ParamListInfo params, struct Param *param,
|
|
|
|
|
struct ExprState *state,
|
|
|
|
|
Datum *resv, bool *resnull);
|
2009-11-04 23:26:08 +01:00
|
|
|
|
|
|
|
|
typedef void (*ParserSetupHook) (struct ParseState *pstate, void *arg);
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
typedef struct ParamListInfoData
|
|
|
|
|
{
|
2009-11-04 23:26:08 +01:00
|
|
|
ParamFetchHook paramFetch; /* parameter fetch hook */
|
|
|
|
|
void *paramFetchArg;
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
ParamCompileHook paramCompile; /* parameter compile hook */
|
|
|
|
|
void *paramCompileArg;
|
2009-11-04 23:26:08 +01:00
|
|
|
ParserSetupHook parserSetup; /* parser setup hook */
|
|
|
|
|
void *parserSetupArg;
|
2019-12-11 22:03:35 +01:00
|
|
|
char *paramValuesStr; /* params as a single string for errors */
|
Rearrange execution of PARAM_EXTERN Params for plpgsql's benefit.
This patch does three interrelated things:
* Create a new expression execution step type EEOP_PARAM_CALLBACK
and add the infrastructure needed for add-on modules to generate that.
As discussed, the best control mechanism for that seems to be to add
another hook function to ParamListInfo, which will be called by
ExecInitExpr if it's supplied and a PARAM_EXTERN Param is found.
For stand-alone expressions, we add a new entry point to allow the
ParamListInfo to be specified directly, since it can't be retrieved
from the parent plan node's EState.
* Redesign the API for the ParamListInfo paramFetch hook so that the
ParamExternData array can be entirely virtual. This also lets us get rid
of ParamListInfo.paramMask, instead leaving it to the paramFetch hook to
decide which param IDs should be accessible or not. plpgsql_param_fetch
was already doing the identical masking check, so having callers do it too
seemed redundant. While I was at it, I added a "speculative" flag to
paramFetch that the planner can specify as TRUE to avoid unwanted failures.
This solves an ancient problem for plpgsql that it couldn't provide values
of non-DTYPE_VAR variables to the planner for fear of triggering premature
"record not assigned yet" or "field not found" errors during planning.
* Rework plpgsql to get rid of the need for "unshared" parameter lists,
by dint of turning the single ParamListInfo per estate into a nearly
read-only data structure that doesn't instantiate any per-variable data.
Instead, the paramFetch hook controls access to per-variable data and can
make the right decisions on the fly, replacing the cases that we used to
need multiple ParamListInfos for. This might perhaps have been a
performance loss on its own, but by using a paramCompile hook we can
bypass plpgsql_param_fetch entirely during normal query execution.
(It's now only called when, eg, we copy the ParamListInfo into a cursor
portal. copyParamList() or SerializeParamList() effectively instantiate
the virtual parameter array as a simple physical array without a
paramFetch hook, which is what we want in those cases.) This allows
reverting most of commit 6c82d8d1f, though I kept the cosmetic
code-consolidation aspects of that (eg the assign_simple_var function).
Performance testing shows this to be at worst a break-even change,
and it can provide wins ranging up to 20% in test cases involving
accesses to fields of "record" variables. The fact that values of
such variables can now be exposed to the planner might produce wins
in some situations, too, but I've not pursued that angle.
In passing, remove the "parent" pointer from the arguments to
ExecInitExprRec and related functions, instead storing that pointer in a
transient field in ExprState. The ParamListInfo pointer for a stand-alone
expression is handled the same way; we'd otherwise have had to add
yet another recursively-passed-down argument in expression compilation.
Discussion: https://postgr.es/m/32589.1513706441@sss.pgh.pa.us
2017-12-21 18:57:41 +01:00
|
|
|
int numParams; /* nominal/maximum # of Params represented */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* params[] may be of length zero if paramFetch is supplied; otherwise it
|
|
|
|
|
* must be of length numParams.
|
|
|
|
|
*/
|
2015-02-20 06:11:42 +01:00
|
|
|
ParamExternData params[FLEXIBLE_ARRAY_MEMBER];
|
1996-08-28 03:59:28 +02:00
|
|
|
} ParamListInfoData;
|
|
|
|
|
|
2002-11-25 22:29:42 +01:00
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
|
* ParamExecData
|
|
|
|
|
*
|
|
|
|
|
* ParamExecData entries are used for executor internal parameters
|
|
|
|
|
* (that is, values being passed into or out of a sub-query). The
|
|
|
|
|
* paramid of a PARAM_EXEC Param is a (zero-based) index into an
|
|
|
|
|
* array of ParamExecData records, which is referenced through
|
|
|
|
|
* es_param_exec_vals or ecxt_param_exec_vals.
|
|
|
|
|
*
|
2002-12-14 01:17:59 +01:00
|
|
|
* If execPlan is not NULL, it points to a SubPlanState node that needs
|
2002-12-13 20:46:01 +01:00
|
|
|
* to be executed to produce the value. (This is done so that we can have
|
2002-11-25 22:29:42 +01:00
|
|
|
* lazy evaluation of InitPlans: they aren't executed until/unless a
|
|
|
|
|
* result value is needed.) Otherwise the value is assumed to be valid
|
|
|
|
|
* when needed.
|
|
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
|
1998-02-13 04:45:29 +01:00
|
|
|
typedef struct ParamExecData
|
|
|
|
|
{
|
2002-12-14 01:17:59 +01:00
|
|
|
void *execPlan; /* should be "SubPlanState *" */
|
1998-02-13 04:45:29 +01:00
|
|
|
Datum value;
|
|
|
|
|
bool isnull;
|
|
|
|
|
} ParamExecData;
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2019-12-11 22:03:35 +01:00
|
|
|
/* type of argument for ParamsErrorCallback */
|
|
|
|
|
typedef struct ParamsErrorCbData
|
|
|
|
|
{
|
|
|
|
|
const char *portalName;
|
|
|
|
|
ParamListInfo params;
|
|
|
|
|
} ParamsErrorCbData;
|
2004-08-02 03:30:51 +02:00
|
|
|
|
|
|
|
|
/* Functions found in src/backend/nodes/params.c */
|
2019-03-14 13:30:09 +01:00
|
|
|
extern ParamListInfo makeParamList(int numParams);
|
2004-08-02 03:30:51 +02:00
|
|
|
extern ParamListInfo copyParamList(ParamListInfo from);
|
2015-09-29 03:55:57 +02:00
|
|
|
extern Size EstimateParamListSpace(ParamListInfo paramLI);
|
|
|
|
|
extern void SerializeParamList(ParamListInfo paramLI, char **start_address);
|
|
|
|
|
extern ParamListInfo RestoreParamList(char **start_address);
|
2019-12-11 22:03:35 +01:00
|
|
|
extern char *BuildParamLogString(ParamListInfo params, char **paramTextValues,
|
|
|
|
|
int valueLen);
|
|
|
|
|
extern void ParamsErrorCallback(void *arg);
|
2004-08-02 03:30:51 +02:00
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
#endif /* PARAMS_H */
|
