Обсуждение: Anyone tried PG with Perl 5.10?

I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
it will work with plperl and/or DBD::Pg?  If there are fixes needed
in plperl, it'd sure be nice if they were in 8.3 ...
        regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
> it will work with plperl and/or DBD::Pg?  If there are fixes needed
> in plperl, it'd sure be nice if they were in 8.3 ...

I've tested 5.10 against both and they seem to work fine. My plperl tests
are not necessarily thorough, but it compiled smoothly and ran a bunch of
plperlu code without a problem. DBD::Pg worked fine, all its tests passed.

-----BEGIN PGP SIGNATURE-----

iD8DBQFHlLMevJuQZxSWSsgRA4neAJoCJtcPusA86PBpZHsmnSWyeKroQACg1CcS
jVgOjqD8ousq5jxIJq3+Sbc=
=XzXA
-----END PGP SIGNATURE-----

Greg Sabino Mullane wrote:
>> I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
>> it will work with plperl and/or DBD::Pg?  If there are fixes needed
>> in plperl, it'd sure be nice if they were in 8.3 ...
>>     
>
> I've tested 5.10 against both and they seem to work fine. My plperl tests
> are not necessarily thorough, but it compiled smoothly and ran a bunch of
> plperlu code without a problem. DBD::Pg worked fine, all its tests passed.
>
>
>   

For plperl, we need to test at least:
   * standard plperl regression tests   * the UTF8 problem we recently fixed

I can check this out later today.

cheers

andrew

>>> I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
>>> it will work with plperl and/or DBD::Pg?  If there are fixes needed
>>> in plperl, it'd sure be nice if they were in 8.3 ...

I tried and couldn't get the Debian perl 5.10 package installed without having
apt tell me it wanted to uninstall all 700+ other packages.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!

Andrew Dunstan wrote:
>
>
> Greg Sabino Mullane wrote:
>>> I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
>>> it will work with plperl and/or DBD::Pg?  If there are fixes needed
>>> in plperl, it'd sure be nice if they were in 8.3 ...
>>>     
>>
>> I've tested 5.10 against both and they seem to work fine. My plperl 
>> tests
>> are not necessarily thorough, but it compiled smoothly and ran a 
>> bunch of
>> plperlu code without a problem. DBD::Pg worked fine, all its tests 
>> passed.
>>
>>
>>   
>
> For plperl, we need to test at least:
>
>    * standard plperl regression tests
>    * the UTF8 problem we recently fixed
>
>

First news is not good. On my test we have failed one of the regression 
tests - the "use strict" processing seems to be backwards. I will try to 
get to the bottom of it.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>>
>>
>> Greg Sabino Mullane wrote:
>>>> I read that Perl 5.10 is about to hit Fedora rawhide.  Anyone know if
>>>> it will work with plperl and/or DBD::Pg?  If there are fixes needed
>>>> in plperl, it'd sure be nice if they were in 8.3 ...
>>>>     
>>>
>>> I've tested 5.10 against both and they seem to work fine. My plperl 
>>> tests
>>> are not necessarily thorough, but it compiled smoothly and ran a 
>>> bunch of
>>> plperlu code without a problem. DBD::Pg worked fine, all its tests 
>>> passed.
>>>
>>>
>>>   
>>
>> For plperl, we need to test at least:
>>
>>    * standard plperl regression tests
>>    * the UTF8 problem we recently fixed
>>
>>
>
> First news is not good. On my test we have failed one of the 
> regression tests - the "use strict" processing seems to be backwards. 
> I will try to get to the bottom of it.
>
>

This problem has been identified by Simon Cozens as a bug in perl 5.10 
(in that it is an undocumented change in Safe.pm). he will file a perl 
bug report on it. The small patch below (also his suggestion, more or 
less) fixes the problem. We turn on access to the caller opcode just 
while we load the strict module. This should be perfectly safe. I intend 
to apply it shortly and to backpatch it, unless there's an objection.

The UTF8 code appears to be still working, which was the other concern I 
had.

cheers

andrew

Index: plperl.c
===================================================================
RCS file: /cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.134
diff -c -u -r1.134 plperl.c
cvs diff: conflicting specifications of output style
--- plperl.c    1 Dec 2007 17:58:42 -0000       1.134
+++ plperl.c    22 Jan 2008 02:31:08 -0000
@@ -272,8 +272,8 @@       "sub ::mksafefunc {" \       "      my $ret = $PLContainer->reval(qq[sub { $_[0] $_[1] }]); "
\      "      $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }" \
 
-       "$PLContainer->permit('require'); $PLContainer->reval('use 
strict;');" \
-       "$PLContainer->deny('require');" \
+       "$PLContainer->permit(qw[require caller]); 
$PLContainer->reval('use strict;');" \
+       "$PLContainer->deny(qw[require caller]); " \       "sub ::mk_strict_safefunc {" \       "      my $ret =
$PLContainer->reval(qq[sub{ BEGIN { 
 
strict->import(); } $_[0] $_[1] }]); " \       "      $@ =~ s/\\(eval \\d+\\) //g if $@; return $ret; }"