Re: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting

John Worsley <lx(at)openvein(dot)com> writes:
> I just stumbled across this peculiarity in PL/Perl today writing a method
> to invoke Perl Regexes from a function: if a run-time error is raised in
> an otherwise good function, the function will never 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 successfully.

That seems a little weird. Does Perl really expect people to do that
(ie, is it a documented part of some API)? I wonder whether there is
some other action that we're supposed to take instead, but are
missing...

> src/pl/plperl/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.");

If this is what we'd have to do, I think a better way would be

perlerrmsg = pstrdup(SvPV(ERRSV, PL_na));
sv_setpv(perl_get_sv("@",FALSE),"");
elog(ERROR, "plperl: error from function: %s", perlerrmsg);

Splitting the ERROR into a NOTICE with the useful info and an ERROR
without any isn't real good, because the NOTICE could get dropped on the
floor (either because of min_message_level or a client that just plain
loses notices).

regards, tom lane