Re: Package namespace and Safe init cleanup for plperl [PATCH]
От | Alex Hunsaker |
---|---|
Тема | Re: Package namespace and Safe init cleanup for plperl [PATCH] |
Дата | |
Msg-id | 34d269d41002121330x6ad3ab6bi89a257f3de3de582@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Package namespace and Safe init cleanup for plperl [PATCH] (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Package namespace and Safe init cleanup for plperl
[PATCH]
Re: Package namespace and Safe init cleanup for plperl [PATCH] |
Список | pgsql-hackers |
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan <andrew@dunslane.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*
В списке pgsql-hackers по дате отправления: