On Jan 28, 2010, at 12:01 PM, Tim Bunce wrote:
> Once the previous patch lands I'll post an update to this patch with
> those changes applied.
Ds the "Add on_perl_init and proper destruction to plperl" patch the one you're
waiting on, then?
Best,
David, who loses track of these things
--
Sent
On Thu, Jan 28, 2010 at 11:54:08AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I think the only controversial change is this one:
>
> >> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
> >> Both are PGC_USERSET.
> >> SPI functions are not available when the code is run.
> >> Er
On Thu, Jan 28, 2010 at 12:12:58PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Tom Lane wrote:
> >> Isn't it a security hole if on_trusted_init is USERSET? That means
> >> an unprivileged user can determine what will happen in plperlu.
> >> SUSET would be saner.
>
> > ITYM on_untrusted_i
Andrew Dunstan writes:
> Tom Lane wrote:
>> Isn't it a security hole if on_trusted_init is USERSET? That means
>> an unprivileged user can determine what will happen in plperlu.
>> SUSET would be saner.
> ITYM on_untrusted_init.
Right, sorry, got 'em backwards.
regards,
Tom Lane wrote:
Isn't it a security hole if on_trusted_init is USERSET? That means
an unprivileged user can determine what will happen in plperlu.
SUSET would be saner.
ITYM on_untrusted_init.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Tim Bunce writes:
> I think the only controversial change is this one:
>> - Adds plperl.on_trusted_init and plperl.on_untrusted_init GUCs
>> Both are PGC_USERSET.
>> SPI functions are not available when the code is run.
>> Errors are detected and reported as ereport(ERROR, ...)
> + plperl.on_
Now the dust is settling on the on_perl_init patch I'd like to ask for
clarification on this next patch.
On Fri, Jan 15, 2010 at 12:35:06AM +, Tim Bunce wrote:
> This is the fourth of the patches to be split out from the former
> 'plperl feature patch 1'.
>
> Changes in this patch:
I think t
