From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | John Worsley <lx(at)openvein(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [GENERAL] [PATCH] PL/Perl (Mis-)Behavior with Runtime Error Reporting |
Date: | 2002-10-20 03:01:18 |
Message-ID: | 200210200301.g9K31IN23859@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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(at)openvein(dot)com
>
Content-Description:
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2002-10-20 15:27:15 | Using current_database() in a grant |
Previous Message | none R Ransbottom | 2002-10-19 23:08:29 | Comparing Databases |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-10-20 03:49:46 | Re: New SET/autocommit problem |
Previous Message | Bruce Momjian | 2002-10-20 02:56:49 | New SET/autocommit problem |