On 22.10.2010 06:10, Tom Lane wrote:
> Right at the moment I'm not seeing any way that the present
> exec_eval_simple_expr approach can be fixed to work safely in the
> presence of recursion. What I think we might have to do is give up
> on the idea of caching execution state trees across calls, instead
> using them just for the duration of a single plpgsql function call.
> I'm not sure what sort of runtime penalty might ensue. The whole design
> predates the plancache, and I think it was mostly intended to prevent
> having to re-parse-and-plan simple expressions every time. So a lot of
> that overhead has gone away anyway given the plancache, and maybe we
> shouldn't sweat too much about paying what remains.
We should test and measure that.
> (But on the third
> hand, what are we gonna do for back-patching to versions without the
> plancache?)
One simple idea is to keep a flag along with the executor state to
indicate that the executor state is currently in use. Set it just before
calling ExecEvalExpr, and reset afterwards. If the flag is already set
in the beginning of exec_eval_simple_expr, we have recursed, and must
create a new executor state.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com