Heikki Linnakangas writes:
> There's a related issue:
> ...
> This one is simple to fix, we can always call exec_eval_cleanup() before
> running the exception handler:
Sounds good, will add that and some regression tests and commit.
regards, tom lane
--
Sent via pgsql-
On 09/08/10 19:32, Tom Lane wrote:
I wrote:
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 i
I wrote:
> 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
Heikki Linnakangas 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