On Dec 4, 2009, at 3:18 AM, Tim Bunce wrote:
> The perl code in plperl.on_perl_init gets eval'd as soon as an
> interpreter is created. That could be at server startup if
> shared_preload_libraries is used. plperl.on_perl_init can only be set by
> an admin (PGC_SUSET).
Are multiline GUCs allowed in the postgresql.conf file?
> The perl code in plperl.on_trusted_init gets eval'd when an interpreter
> is initialized into trusted mode, e.g., used for the plperl language.
> The perl code is eval'd inside the Safe compartment.
> plperl.on_trusted_init can be set by users but it's only useful if set
> before the plperl interpreter is first used.
So immediately after connecting would be the place to make sure you do it, IOW.
> plperl.on_untrusted_init acts like plperl.on_trusted_init but for
> plperlu code.
>
> So, if all three were set then, before any perl stored procedure or DO
> block is executed, the interpreter would have executed either
> on_perl_init and then on_trusted_init (for plperl), or on_perl_init and
> then on_untrusted_init (for plperlu).
Awesome, thanks! This is really a great feature.
>> along with quote_nullable(), which might also be useful to add.
>
> I was planning to build that behaviour into quote_literal since it fits
> naturally into perl's idea of undef and mirrors DBI's quote() method.
> So:
> quote_literal(undef) => "NULL"
> quote_literal('foo') => "'foo'"
Is there an existing `quote_literal()` in PL/Perl? If so, you might not want to
change its behavior.
>>> - generalize the Safe setup code to enable more control.
>
> Specifically control what gets loaded into the Compartment, what gets
> shared with it (e.g. sharing *a & *b as a workaround for the sort bug),
> and what class to use for Safe (to enable deeper changes if desired via
> subclassing). Naturally all this is only possible for admin (via
> plperl.on_perl_init).
Sounds good.
>>> - formalize namespace usage, moving things out of main::
>>
>> Nice.
>>
>>> - add a way to perform inter-sub calling (at least for simple cases).
>
> My current plan here is to use an SP::AUTOLOAD to handle loading and
> dispatching. So calling SP::some_random_procedure(...) will trigger
> SP::AUTOLOAD to try to resolve "some_random_procedure" to a particular
> stored procedure. There are three tricky parts: handling polymorphism (at
> least "well enough"), making autoloading of stored procedures work
> inside Safe, making it fast. I think I have reasonable approaches for
> those but I won't know for sure till I work on it.
I'm wondering if there might be some way to use some sort of attributes to
identify data types passed to a PL/Perl function called from another PL/Perl
function. Maybe some other functions that identify types, in the case of
ambiguities?
foo(int(1), text('bar'));
? Kind of ugly, but perhaps only to be used if there are ambiguities? Not sure
it's a great idea, mind. Just thinking out loud (so to speak).
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
