pgsql: Work around for perl 5.10 bug - fix due to perl hacker Simon

Started by Andrew Dunstanover 18 years ago5 messagescomitters
Jump to latest
#1Andrew Dunstan
andrew@dunslane.net

Log Message:
-----------
Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens.

Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.134 -> r1.135)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.134&r2=1.135)

#2Neil Conway
neilc@samurai.com
In reply to: Andrew Dunstan (#1)
Re: pgsql: Work around for perl 5.10 bug - fix due to perl hacker Simon

More information in the commit message would be good to see (for the
sake of the CVS history, if nothing else).

-Neil

Show quoted text

On Tue, 2008-01-22 at 20:17 +0000, Andrew Dunstan wrote:

Log Message:
-----------
Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens.

Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.134 -> r1.135)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.134&r2=1.135)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Neil Conway (#2)
Re: pgsql: Work around for perl 5.10 bug - fix due to perl hacker Simon

I don't actually have a lot of information. Simon told me that, due to a
change in behaviour which he described as a bug, we need to enable the
caller opcode during the load of the strict module, and that we could
turn it off again once the module was imported. That's what I did (after
testing). It's a tiny and quite safe change. If you like I will add a
note to the code saying why it's there.

cheers

andrew

Neil Conway wrote:

Show quoted text

More information in the commit message would be good to see (for the
sake of the CVS history, if nothing else).

-Neil

On Tue, 2008-01-22 at 20:17 +0000, Andrew Dunstan wrote:

Log Message:
-----------
Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens.

Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.134 -> r1.135)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.134&r2=1.135)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

#4Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#3)
Re: pgsql: Work around for perl 5.10 bug - fix due to perl hacker Simon

Andrew Dunstan wrote:

I don't actually have a lot of information. Simon told me that, due to a
change in behaviour which he described as a bug, we need to enable the
caller opcode during the load of the strict module, and that we could
turn it off again once the module was imported. That's what I did (after
testing). It's a tiny and quite safe change. If you like I will add a
note to the code saying why it's there.

If 'require' is the typical way of doing this, and 'requier caller' is a
rare method, then the big problem is not the commit message but the lack
of description in the code as to why we are doing this. It is unlikely
anyone will remember why we made this change, and what version of Perl
it is supposed to fix so we can revert it later perhaps.

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

cheers

andrew

Neil Conway wrote:

More information in the commit message would be good to see (for the
sake of the CVS history, if nothing else).

-Neil

On Tue, 2008-01-22 at 20:17 +0000, Andrew Dunstan wrote:

Log Message:
-----------
Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens.

Modified Files:
--------------
pgsql/src/pl/plperl:
plperl.c (r1.134 -> r1.135)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c?r1=1.134&r2=1.135)

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

#5Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#4)
Re: pgsql: Work around for perl 5.10 bug - fix due to perl hacker Simon

Bruce Momjian wrote:

Andrew Dunstan wrote:

I don't actually have a lot of information. Simon told me that, due to a
change in behaviour which he described as a bug, we need to enable the
caller opcode during the load of the strict module, and that we could
turn it off again once the module was imported. That's what I did (after
testing). It's a tiny and quite safe change. If you like I will add a
note to the code saying why it's there.

If 'require' is the typical way of doing this, and 'requier caller' is a
rare method, then the big problem is not the commit message but the lack
of description in the code as to why we are doing this. It is unlikely
anyone will remember why we made this change, and what version of Perl
it is supposed to fix so we can revert it later perhaps.

We are not doing "require caller". "require" and "caller" are the names
of two separate sets of opcodes. We always needed "require" here, as
that is what we need enabled to execute the "use strict" instruction (or
indeed any "use" instruction). We added the "caller" opcode to the list
of allowed directives, because the Safe module now apparently uses it
when loading a module (e.g. when doing "use Foo;").

Anyway, as you saw later, I have added a comment to the code.

Don't be surprised if this never gets fixed in Perl - it's more likely
that they will document the behaviour, I think.

cheers

andrew