In a recent post I mentioned that I had a PLPERL procedure that
...adds useful definitions, mostly subs, to Perl's main package.
I thought this claim needs further clarification, since the docs for PLPERL
include a warning that may give readers the impression that defining Perl
functions within PLPERL code is somehow problematic. This warning says:
Note: The use of named nested subroutines is dangerous in Perl, especially
> if they refer to lexical variables in the enclosing scope. Because a PL/Perl
> function is wrapped in a subroutine, any named subroutine you create will be
> nested. In general, it is far safer to create anonymous subroutines which
> you call via a coderef.
>
But this is only a problem if one defines functions like this
sub foo {
# blah blah blah
}
which indeed would result in a nested function. But one can define
non-nested functions within other functions (and even "closures" that refer
to lexical variables) by manipulating symbol tables directly. For example:
CREATE FUNCTION make_closure ( TEXT ) RETURNS void
AS $PERL$
my $lexical = shift;
*the_closure = sub { return '>> ' . $lexical };
$PERL$ LANGUAGE plperl IMMUTABLE;
CREATE FUNCTION test_closure () RETURNS TEXT
AS $PERL$
return the_closure();
$PERL$ LANGUAGE plperl VOLATILE;
First, we show that the perl function the_closure (or more precisely,
main::the_closure) has not been defined yet.
SELECT * from test_closure();
ERROR: error from Perl function: Undefined subroutine &main::the_closure
called at line 2.
As expected. To define the perl function the_closure, we need to call
make_closure first:
SELECT make_closure( 'foobar' );
SELECT * from test_closure();
test_closure
--------------
>> foobar
(1 row)
Now the PLPERL procedure test_closure() can invoke the perl function
the_closure.
The next (very contrived) example demonstrates that the functions being
defined are indeed closures (note that each of the Perl functions defined
through calls to make_closure2 refers to its own private copy of the
variable $lexical). (Note that this example uses a "soft reference", but
one can achieve the same thing by eval'ing a suitable string).
CREATE FUNCTION make_closure2 ( TEXT, TEXT ) RETURNS void
AS $PERL$
my $closure_name = shift;
my $lexical = shift;
*{ $closure_name } = sub { return '>> ' . $lexical };
return;
$PERL$ LANGUAGE plperlu IMMUTABLE;
CREATE FUNCTION test_closure2 ( TEXT ) RETURNS TEXT
AS $PERL$
my $ret = eval( shift() . '()' );
die if $@;
return $ret;
$PERL$ LANGUAGE plperlu VOLATILE;
SELECT make_closure2( 'first_closure', 'quux' );
SELECT make_closure2( 'second_closure', 'frobozz' );
SELECT * FROM test_closure2( 'first_closure' );
test_closure2
---------------
>> quux
(1 row)
SELECT * FROM test_closure2( 'second_closure' );
test_closure2
---------------
>> frobozz
(1 row)
And the functions need not to be defined in the main package. For example,
make_closure3 is exactly like make_closure above, except that it defines the
function the_closure in the package Some::Other::Package rather than the
package main. (Similarly, test_closure3 is exactly like test_closure,
except that it invokes Some::Other::Package::the_closure rather than
main::the_closure.)
CREATE FUNCTION make_closure3 ( TEXT ) RETURNS void
AS $PERL$
my $lexical = shift;
*Some::Other::Package::the_closure = sub { return '>> ' . $lexical };
$PERL$ LANGUAGE plperl IMMUTABLE;
CREATE FUNCTION test_closure3 () RETURNS TEXT
AS $PERL$
return Some::Other::Package::the_closure();
$PERL$ LANGUAGE plperl VOLATILE;
SELECT make_closure3( 'mwa-ha-ha-ha-ha!' );
SELECT * from test_closure3();
test_closure3
---------------------
>> mwa-ha-ha-ha-ha!
(1 row)
I want to point out that such symbol-table manipulations are entirely
standard. For example, the standard Perl module Exporter uses this
technique to install functions and variables in the calling package's
namespace.
Kynn
