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