Re: Package namespace and Safe init cleanup for plperl [PATCH]

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org, "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]
Date: 2010-02-12 21:30:37
Message-ID: 34d269d41002121330x6ad3ab6bi89a257f3de3de582@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> Alex Hunsaker wrote:
>>>>
>>>> in plc_safe_ok.pl
>>>> +use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
>>>> ...the *_init gucs to be able to stick things into
>>>> @ShareIntoSafe and friends?
>
> I'm not sure it's fine with me.
>
> I'm a bit inclined to commit the piece of this patch that concerns the
> warnings pragma,

I think a sizable portion of the patch can be dropped if you do the
above. Namely the whole double init protection that got added in the
last round.

> and leave the rest for the next release, unless you can
> convince me real fast that we're not opening a back door here. If we're
> going to allow DBAs to add things to the Safe container, it's going to be up
> front or not at all, as far as I'm concerned.

I think backdoor is a bit extreme. Yes it could allow people who
can set the plperl.*_init functions to muck with the safe. As an
admin I could also do that by setting plperl.on_init and overloading
subs in the Safe namespace or switching out Safe.pm.

Anyway reasons I can come up for it are:
-its general so we can add other modules/pragmas easily in the future
-helps with the plperl/plperlu all or nothing situation
-starts to flesh out how an actual exposed (read documented) interface
should look for 9.1

... I know Tim mentioned David as having some use cases (cc'ed)

So my $0.2 is I don't have any strong feelings for/against it. I
think if we could expose *something* (even if you can only get to it
in a C contrib module) that would be great. But I realize it might be
impractical at this stage in the game.

*shrug*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arie Bikker 2010-02-12 21:32:08 xpath improvement V2
Previous Message Robert Haas 2010-02-12 21:29:26 Re: knngist patch support