Re: plperl strict mode

The attached patch (submitted for testing and comment) allows turning on
perl strict mode via a GUC setting for plperl/plperlu. (plplerlu users
would be able to turn it off again, but plperl users would not, I think.
Certainly not straightforwardly at least.

In order to protect legacy code, the default is to have strict mode off.

For those who are not perl savvy, strict mode disallows some
quick-and-dirty coding methods that are mostly really hangovers from the
days of perl 4, expecially use of undeclared variables and use of bare
words in circumstances where they might be ambiguous. Turning strict
mode on is a common requirement in corporate coding standards (including
some I have written).

This feature has been requested by several plperl users, as well as
scratching my own itch ;-)

Illustration: with this in postgresql.conf:

custom_variable_classes = 'plperl'
plperl.use_strict = true

it works like this:

andrew=# create or replace function foo() returns text language plperl
as $$ $x = 1; return 'hello'; $$;
CREATE FUNCTION
andrew=# select foo();
ERROR: creation of Perl function failed: Global symbol "$x" requires
explicit package name at (eval 11) line 1.
andrew=# create or replace function foo() returns text language plperl
as $$ my $x = 1; return 'hello'; $$;
CREATE FUNCTION
andrew=# select foo();
foo
-------
hello

Note that in the second case $x is declared as a lexical variable,
whereas in the first (failing) case it is an undeclared global.

There is one problem ... it blew up if I used a context setting of
anything more strict than PGC_USERSET. But rally, that's not good. It
needs to be set at the time we make the functions that set up the
anonymous subs ... i.e. at interpreter startup. Anything later will be
ginored anyway. So I'd like to find a way to do that.

cheers

andrew

On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:

Andrew,

> it works like this:
>
> andrew=# create or replace function foo() returns text language plperl
> as $$ $x = 1; return 'hello'; $$;
> CREATE FUNCTION
> andrew=# select foo();
> ERROR: creation of Perl function failed: Global symbol "$x" requires
> explicit package name at (eval 11) line 1.

Hmm, is there a way to have a validator function and have the strict
check at function creation too? I know these things are reported with
perl -c, not sure if they can be reached with the C interface.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
Dios hizo a Adán, pero fue Eva quien lo hizo hombre.

Alvaro Herrera wrote:

>On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
>
>Andrew,
>
>
>
>>it works like this:
>>
>>andrew=# create or replace function foo() returns text language plperl
>>as $$ $x = 1; return 'hello'; $$;
>>CREATE FUNCTION
>>andrew=# select foo();
>>ERROR: creation of Perl function failed: Global symbol "$x" requires
>>explicit package name at (eval 11) line 1.
>>
>>
>
>Hmm, is there a way to have a validator function and have the strict
>check at function creation too? I know these things are reported with
>perl -c, not sure if they can be reached with the C interface.
>
>
>
>

Maybe I have missed it, but I don't see an exposed interface that is
called when we create a function, only one to set up the interpreter and
one where we call the function (which compiles it if it isn't already
compiled). If there is some way that we can force a call into the
module when a CREATE OR REPLACE FUNCTION is issued, then it should be
quite possible to get compile errors. That would strike me as being a
very good thing.

cheers

andrew

On Tue, May 24, 2005 at 11:53:45AM -0400, Andrew Dunstan wrote:

> Alvaro Herrera wrote:
>
> >On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
> >
> >Hmm, is there a way to have a validator function and have the strict
> >check at function creation too? I know these things are reported with
> >perl -c, not sure if they can be reached with the C interface.
>
> Maybe I have missed it, but I don't see an exposed interface that is
> called when we create a function, only one to set up the interpreter and
> one where we call the function (which compiles it if it isn't already
> compiled).

Yes, you can register a function as "validator" during language
creation. AFAIR there are no validator functions except SQL and
plpgsql, so you would have to create one for plperl ...

--
Alvaro Herrera (<alvherre[a]surnet.cl>)

Alvaro Herrera wrote:

>Yes, you can register a function as "validator" during language
>creation. AFAIR there are no validator functions except SQL and
>plpgsql, so you would have to create one for plperl ...
>
>
>

Excellent. We'll definitely work on that. Not having this has annoyed me
(and I'm sure others) in the past.

cheers

andrew