[PATCH] PL/Perl (Mis-)Behavior with Runtime Error Reporting
От | John Worsley |
---|---|
Тема | [PATCH] PL/Perl (Mis-)Behavior with Runtime Error Reporting |
Дата | |
Msg-id | Pine.LNX.4.21.0210021600230.5468-200000@baby.audiophonic.com обсуждение исходный текст |
Список | pgsql-general |
Good day, I just stumbled across this peculiarity in PL/Perl today writing a method toinvoke Perl Regexes from a function: if a run-time error is raised in an otherwise good function, the function will not run correctly again until the connection to the database is reset. I poked around in the code and it appears that it's because when elog() raises the ERROR, it doesn't first take action to erase the system error message ($@) and consequently every subsequent run has an error raised, even if it runs succesfully. For example: -- This comparison works fine. template1=# SELECT perl_re_match('test', 'test'); perl_re_match --------------- t (1 row) -- This one dies, for obvious reasons. template1=# SELECT perl_re_match('test', 't{1}+?'); ERROR: plperl: error from function: (in cleanup) Nested quantifiers before HERE mark in regex m/t{1}+ << HERE ?/ at (eval 2) line 4. -- This should work fine again, but we still have this error raised...! template1=# SELECT perl_re_match('test', 'test'); ERROR: plperl: error from function: (in cleanup) Nested quantifiers before HERE mark in regex m/t{1}+ << HERE ?/ at (eval 2) line 4. I don't know if the following is the best way to solve it, but I got around it by modifying the error report in this part of PL/Perl to be a NOTICE, cleared the $@ variable, and then raised the fatal ERROR. A simple three line patch to plperl.c follows, and is attached. plperl.c: 443c443,445 < elog(ERROR, "plperl: error from function: %s", SvPV(ERRSV, PL_na)); --- > elog(NOTICE, "plperl: error from function: %s", SvPV(ERRSV, PL_na)); > sv_setpv(perl_get_sv("@",FALSE),""); > elog(ERROR, "plperl: error was fatal."); Best Regards, Jw. -- John Worsley - lx@openvein.com
Вложения
В списке pgsql-general по дате отправления: