Re: Wishlist of PL/Perl Enhancements for PostgreSQL 8.5

On Mon, Oct 05, 2009 at 11:25:18PM +0100, Tim Bunce wrote:
> I'm planning to work with Andrew Dunstan on some enhancements to PL/Perl
> for PostgreSQL 8.5.
>
> I've written up some initial proposals here:
>
> http://blog.timbunce.org/2009/10/05/wishlist-of-plperl-enhancements-for-postgresql-8-5/
>
> I'd welcome any feedback on those, and any other suggestions you may have.
> (Either here, on the blog, or direct to me - I'll post a summary.)

I've posted the bulk of the text (including some minor updates) below
to make commenting here easier.

Tim.

Goals:

- Enable modular programming by pre-loading user libraries.
- Soften the hard choice between plperl and plperlu, so there’s less reason to “give up” and use plperlu.
- Improve performance.
- Improve flexibility for future changes.
- Enable use of tracing/debugging tools.

Specific Proposals:

* Enable configuration of perl at initialization

Add ability to specify in postgresql.conf some code to be run when a
perl interpreter is initialized. For example:

plperl.at_init_do = 'use lib qw(/path/to/mylib); use MyPlPerlUtils; use List::Util qw(sum);'

* Configure extra items to be shared with the Safe compartment

The Safe compartment used for plperl functions can’t access any
namespace outside the compartment. So, by default, any subroutines
defined by libraries loaded via plperl.at_init_do won’t be callable from
plperl functions.

Some mechanism is needed to specify which extra subroutines, and/or
variables, should be shared with the Safe compartment. For example:

plperl.safe_share = '$foo, myfunc, sum'

* Permit some more opcodes in the Safe compartment

I’d like to add the following opcodes to the set of opcodes permitted in
the Safe compartment: caller, dbstate, tms.

* Execute END blocks at process end

Currently PostgreSQL doesn’t execute END blocks when the backend
postgres process exits (oddly, it actually executes them immediately
after initializing the interpreter). Fixing that would greatly simplify
use of tools like NYTProf that need to know when the interpreter is exiting.

* Name PL/Perl functions

Currently PL/Perl functions are compiled as anonymous subroutines.
Applying the same technique as the Sub::Name module would allow them
have ‘more useful’ names than the current ‘__ANON__’.

For a PL/Perl function called “foo”, a minimal implementation would use
a name like “foo__id54321″ where 54321 is the oid of the function. This
avoids having to deal with polymorphic functions (where multiple
functions have the same name but different arguments).

The names won’t enable inter-function calling and may not even be
installed in the symbol table. They’re just to improve error messages
and to enable use of tools like Devel::NYTProf::PgPLPerl