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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
