Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> TRAP: FailedAssertion("!(estate->eval_tuptable == ((void *)0))", File:
> "pl_exec.c", Line: 4264)
> This happens when both the array subscript and the expression been
> assigned are "non-simple". The purpose of the funny-looking COALESCE
> expressions in the above example is to force them to be non-simple.
Ugh. I'm amazed we didn't find this long ago.
> The problem is that exec_assign_value() is passed a value that came from
> the current 'estate', but when exec_assign_value() evaluates the array
> subscript, we don't expect there to already be an open result set in
> 'estate'.
> A simple fix would be to make a copy of the value being assigned in
> exec_assign_expr and calling exec_eval_cleanup() before the call to
> exec_assign_value(). But I wonder if the performance impact would be too
> high - one extra copy isn't that expensive, but it would affect every
> single assignment of pass-by-reference variables.
Yeah, I don't like that either. What we need to do instead is fix
exec_assign_value so that it can cope with the case of the caller having
an open expression evaluation. We can easily have it save/restore
eval_tuptable. Not resetting eval_econtext is a bit harder, but maybe
we could have a use-count variable ... or even easier, just decree that
the caller has to do exec_eval_cleanup after calling exec_assign_value,
whether or not it had an open expression eval.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
