Re: [HACKERS] 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- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 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! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 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.c1 Dec 2007 17:58:42 - 1.134
+++ plperl.c22 Jan 2008 02:31:08 -
@@ -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; }
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[HACKERS] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
