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 chang
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
-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 pra
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 chec
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 ei
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:
> 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.
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 appear
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.
A
