On 26.05.2011 00:31, Tom Lane wrote:
> The main annoyance here is that standalone expressions may now need
> Param slots to execute, which will complicate places that need to
> evaluate them, but there's probably no way around that
Yeah, I can see two complications:
1. Domain constraints
Domain constraint check expressions are fetched and constant-folded
separately from the enclosing expression, in ExecInitExpr(). In order to
allocate distinct paramids for any CASE values within the domain check
expression, we'd need to know how many paramids are in use in the parent
expression. We could dig into the parent PlanState and its EState to get
that, but we don't have that for stand-alone expressions.
2. Index expressions
Index expressions are stored in relcache after constant evaluation, so
any CaseTestExprs will already be replaced with Params. When the recheck
expression is evaluated, the paramids used in the recheck expression
will clash with real PARAM_EXEC params used to pass values up and down
subqueries, as well as any params used for CASEs.
I think we can work around both of those by just saving and restoring
the value of each Param that we set while evaluating an expression, as
the values should not be used simultaneously, but it makes me a bit
uncomfortable. If we ever try to inline those expressions into other
expressions, we'll be right back to the issue we have with nested CASE
now. I'm not sure if we might already do that for index recheck
expressions. Alternatively, we could adjust the paramids when an
expression is inlined into another, similar to what OffsetVarNodes does
for Vars.
For debugging purposes, it seems like a good idea to invent a new kind
of Param for these, and keep them separate from PARAM_EXEC params. The
scope would be different, PARAM_EXECs are used to pass values between
planner nodes, while these new kind of Params would be used to pass
values within a single expression.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
