The Perl community have been great supporters of Postgres, and that's partly why PL/Perl is one of the most feature laden PLs around, as well as why DBI+DBD::Pg is one of the best client drivers around.
Now Tim Bunce, of DBI fame (among other things), has come along with some features and improvements for PL/Perl that will once again show that Perl + Postgres is just a great combination.
Already committed is his initial work on refactoring and tidying up the code, making it both easier to read and maintain, and more efficient in several respects. To go with this I have added some improved infrastructure that allows regression tests for both plperlu (the untrusted variety of PL/Plerl) and plperl+plperlu in combination. Up to now we only had provision for regression testing plperl, the trusted variety.
But there's much more coming. Tim has published a feature patch with all of the following:
- 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.
- 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.
- New utility functions: quote_literal, quote_nullable, quote_ident,
encode_bytea, decode_bytea, looks_like_number,
encode_array_literal, encode_array_constructor.
- Enable plperl to "use"/"require" safely by redirecting the require
opcode to code that dies if module not already loaded.
That's a lot of stuff, and maybe not all of it will make it into this new release, although I'm hopeful most of it will. The utility finctions will be both useful and a substantial efficiency gain. The initialization stuff, and the ability to preload certain modules (c.f. mod_perl) will make it much more attractive to create large applications using PL/Perl functions.
Currently, I use PL/Perl in two cases: first where I need to interact with something outside the database (the file system, another database system like SQLServer, atc.), or where I need some advanced facility Perl has that I can't easily get using PL/PGSQL. These changes will probably tip the balance more towards Pl/Perl.
