Anyone tried PG with Perl 5.10?

Started by Tom Lanealmost 18 years ago6 messages
#1Tom Lane
tgl@sss.pgh.pa.us

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

#2Greg Sabino Mullane
greg@turnstep.com
In reply to: Tom Lane (#1)
Re: Anyone tried PG with Perl 5.10?

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

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Greg Sabino Mullane (#2)
Re: Anyone tried PG with Perl 5.10?

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

#4Gregory Stark
stark@enterprisedb.com
In reply to: Andrew Dunstan (#3)
Re: 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 ...

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!

#5Andrew Dunstan
andrew@dunslane.net
In reply to: Andrew Dunstan (#3)
Re: Anyone tried PG with Perl 5.10?

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

#6Andrew Dunstan
andrew@dunslane.net
In reply to: Andrew Dunstan (#5)
Re: Anyone tried PG with Perl 5.10?

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; }"