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

On Thu, Dec 03, 2009 at 04:53:47PM -0800, David E. Wheeler wrote:
> On Dec 3, 2009, at 3:30 PM, Tim Bunce wrote:
> 
> > - New GUC plperl.on_perl_init='...perl...' for admin use.
> > - New GUC plperl.on_trusted_init='...perl...' for plperl user use.
> > - New GUC plperl.on_untrusted_init='...perl...' for plperlu user use.
> 
> Since there is no documentation yet, how do these work, exactly? Or should I just wait for the docs?

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).

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.

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).

> > - END blocks now run at backend exit (fixes bug #5066).
> > - Stored procedure subs are now given names ($name__$oid).
> > - More error checking and reporting.
> > - Warnings no longer have an extra newline in the NOTICE text.
> > - Various minor optimizations like pre-growing data structures.
> 
> Nice.

Thanks.

> > I'm working on adding tests and documentation now, meanwhile I'd very
> > much appreciate any feedback on the patch.
> > 
> > Tim.
> > 
> > p.s. Once this patch is complete I plan to work on patches that:
> > - add quote_literal and quote_identifier functions in C.
> 
> I expect you can just use the C versions in PostgreSQL. They're in utils/builtins.h,

That's my plan. (I've been discussing this and other issues with Andrew
Dunstan via IM.)

> 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'"

> > - 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).

> > - 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.

> > - possibly rewrite _plperl_to_pg_array in C.
> 
> Sounds great, Tim. I'm not really qualified to say anything about the
> C code, but I'd be happy to try it out once there are docs.

Great. Thanks David.

Tim.