Re: PL/Perl embedding string common elements - Mailing list pgsql-patches

Tom Lane wrote:

>Michael Fuhr <mike@fuhr.org> 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.
>>
>>
>
>Actually, it strikes me that this is working around a problem that
>we shouldn't have in the first place: there should not be two different
>embedding strings.  I hadn't noticed the use_strict GUC before, but
>now that I see it, I think it's implemented in a completely awful
>way.  Because the embedding string is only executed once per backend,
>it's effectively impossible to change use_strict on the fly.  I think
>we should be looking for another implementation of that feature, rather
>than just cleaning up the minor breakage.  One would expect changes
>in the variable to at least affect future function compilations in
>the current backend, if not indeed recompiling already-compiled ones.
>
>I'm not much of a Perl guru, but could we make this happen by having
>four functions instead of two?  (mksafefunc, mksafestrictfunc, etc)
>I'm not too clear on what the scope of effects of 'use strict' is.
>
>

The intention was to make it settable on startup only. Unfortunately
when I tried that it blew up on me. It seems that the getting of custom
settings happens too late for that to work. I recall posting a message
to -hackers asking for some help on that, but got no response, so I just
made it PGC_USERSET so I could make some progress.

The scope of  "use strict" is from the declaration down to the end of
the enclosing block, file, or eval.

The biggest problem is that "use" is in fact a forbidden operation in
trusted plperl.

If you wanted a simpler (and in a way more perlish) way of enabling
this, we could abandon the GUC var altogether and load the strict module
unconditionally. Then each user function could turn on strict mode at
their choice by calling "strict->import();", possibly in a BEGIN block
(plperlu functions could just have "use strict;").

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. Of course, many people regret that strict mode was not
(mainly so that millions of lines of legacy code didn't break) made the
default in perl5. :-) I know of one ardent plperl advocate at least who
would be highly disappointed if we followed this course. We'd still have
made an advance, because in 8.0 you can't turn on strict mode at all in
trusted plperl.

Of course, we're getting close to Beta, but if you're happy redesigning
things at this stage, we should be able to wrap it up fairly quickly -
it's hardly huge.

cheers

andrew