Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Do you expect turning it on to affect only future compilations? Or
should we recompile every function already compiled in the present
backend? I can see arguments either way.
Yeah, me too. I would definitely expect a change
Tom Lane wrote:
Looking ahead to the future a bit, is there any reason to expect that
use_strict would have cross-function effects? In a normal Perl script
I suppose it does add some cross-function checking.
Not sure what you mean by this. Perl strict mode in fact does very
little
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The biggest problem is that use is in fact a forbidden operation in
trusted plperl.
I would very much like to have use strict available in plperl. Is there
any way at all to simply make an exception for 'use strict' (and perhaps
some other
Greg Sabino Mullane said:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The biggest problem is that use is in fact a forbidden operation in
trusted plperl.
I would very much like to have use strict available in plperl.
You're not alone. That's why we're going through all this.
Is there
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears to be a bug.
Michael Fuhr [EMAIL PROTECTED] writes:
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears to be a bug.
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
The attached patch moves the common elements of loose_embedding[]
and strict_embedding[] to a macro so they can be maintained in
one place. As Tom Lane noticed, ::_plperl_to_pg_array was missing
from strict_embedding[], which appears
Andrew Dunstan [EMAIL PROTECTED] writes:
Every perl module whose author wants strict mode (and they all should)
has to carry such a declaration, so in a sense we'd just be doing what
perl itself does, and by trying to provide a global switch we're being
unperlish.
You missed my point. I
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Every perl module whose author wants strict mode (and they all should)
has to carry such a declaration, so in a sense we'd just be doing what
perl itself does, and by trying to provide a global switch we're being
unperlish.
Andrew Dunstan [EMAIL PROTECTED] writes:
Do you expect turning it on to affect only future compilations? Or
should we recompile every function already compiled in the present
backend? I can see arguments either way.
Yeah, me too. I would definitely expect a change in the variable
(in either
10 matches
Mail list logo
