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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime
Дата
Msg-id 200305240403.h4O43vu01255@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Did we ever address this plperl issue?  I see the code unchanged in CVS.

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

Tom Lane wrote:
> John Worsley <lx@openvein.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

--  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,
Pennsylvania19073
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: more contrib: log rotator
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting