Skip site navigation (1) Skip section navigation (2)

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

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Package namespace and Safe init cleanup for plperl [PATCH]
Date: 2010-02-12 20:42:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Alex Hunsaker wrote:
>>> in
>>> +use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
>>> Is there some reason not to use my here?  The only reason I can think
>>> of is you want the *_init gucs to be able to stick things into
>>> @ShareIntoSafe and friends?  And if so should we document that
>>> somewhere (or was that in an earlier patch that i missed?)?
>> It's a step towards providing an interface to give the DBA control over
>> what gets loaded into the Safe compartment and what gets shared with it.
>> I opted to not try to define a formal documented interface because I
>> felt it was likely to be a source of controversy and/or bikeshedding.
>> This late in the game I didn't want to take that chance.
>> I'd rather a few brave souls get some experience with it as-as, and collect
>> some good use-cases, before proposing a formal documented API.
> Fine with me.

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, 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 hope I haven't misunderstood what's going on here.



In response to


pgsql-hackers by date

Next:From: Oleg BartunovDate: 2010-02-12 20:44:58
Subject: Re: knngist patch support
Previous:From: Robert HaasDate: 2010-02-12 20:06:16
Subject: Re: [PATCH] Provide rowcount for utility SELECTs

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group