Assertion failure with assignment to array elem
От | Heikki Linnakangas |
---|---|
Тема | Assertion failure with assignment to array elem |
Дата | |
Msg-id | 4C5FE9B5.1070500@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Assertion failure with assignment to array elem
|
Список | pgsql-bugs |
postgres=# CREATE OR REPLACE FUNCTION f_test() RETURNS VOID AS $$ DECLARE arr text[]; lr text; i integer; BEGIN i := 1; SELECT 'foo' INTO lr; arr[COALESCE(i, (SELECT NULL::integer))] := COALESCE(lr, (SELECT NULL::text)); END; $$ LANGUAGE PLPGSQL; CREATE FUNCTION postgres=# SELECT f_test(); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. 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. This bug applies to all supported versions. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-bugs по дате отправления: