Re: First feature patch for plperl - draft [PATCH] - Mailing list pgsql-hackers

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
functioncalled 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
outloud (so to speak). 

Best,

David