Thread: On defining Perl functions within PLPERL code

On defining Perl functions within PLPERL code

From
"Kynn Jones"
Date:
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

Re: On defining Perl functions within PLPERL code

From
"Greg Sabino Mullane"
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> 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:

Well, it /is/ problematic, especially for those that don't know Perl well,
but doc patches are welcome. :)

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200803111136
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkfWpxIACgkQvJuQZxSWSsjG8ACgtm/KDquzv8kz0D3Ij4jHJvIG
HNgAoNS5sBTDfXjINj4TEsZdlEAi7mhM
=7pgP
-----END PGP SIGNATURE-----