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

Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
Date: 2010-02-03 13:41:36
Message-ID: 4B697D10.7080807@dunslane.net (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-02-03 13:42:57
Subject: Re: [HACKERS] Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous:From: Rushabh LathiaDate: 2010-02-03 12:49:33
Subject: use of dblink_build_sql_insert() induces a server crash

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