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