Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date
Msg-id 4B697D10.7080807@dunslane.net
Whole thread Raw
In response to Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]  (Alex Hunsaker <badalex@gmail.com>)
Responses Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
List pgsql-hackers

Alex Hunsaker wrote:
>>>> Well its already in.
>>>>         
>>> Well *that's* easily fixed.  I think it's a bad idea, because it's
>>> unclear what you should put there and what the security implications
>>> are.
>>>       
>>  I can't speak for its virtue, maybe Tim, Andrew?
>>     
>
>
>   

plperl.on_perl_init runs when the library is loaded. That makes it 
useful for preloading perl modules and similar tasks. The other two in 
the patch under disccussion run when the relevant interpreter is first 
used in the current session. That makes them appropriate for doing 
things like loading specific initial settings (e.g. in the interpreter's 
%_SHARED).

I'm not going to be pleased if, having had a substantial debate on the 
patch that contained on_perl_init a week or so ago there are now 
attempts to rip it out. As I commented when I committed it:

> The final thing that persuaded me that no great damage would be done 
> by on_perl_init was the realization that we already have the ability 
> to do more or less the same thing anyway via standard Perl mechanisms, 
> and I'd be very surprised if enterprising Perl users hadn't made use 
> of it. 

Regarding the naming of the params, I'm not keen to have more than one 
custom_variable_class for plperl. Within that, maybe we can bikeshed the 
names a bit. I don't have terribly strong feelings.

cheers

andrew


pgsql-hackers by date:

Previous
From: Chris Campbell
Date:
Subject: Recent vendor SSL renegotiation patches break PostgreSQL
Next
From: Robert Haas
Date:
Subject: Re: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)