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
Wed, 2 Oct 2002 16:08:36 -0700 (PDT)
John Worsley <lx@openvein.com>
[PATCH] PL/Perl (Mis-)Behavior with Runtime Error Reporting

John, any resolution on this patch?

---------------------------------------------------------------------------

John Worsley wrote:
> 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
> 

Content-Description: 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Sat, 19 Oct 2002 23:01:18 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [GENERAL] [PATCH] PL/Perl (Mis-)Behavior with Runtime Error
	Reporting