On 12/16/2009 3:15 PM, Peter wrote:
Hello Tim,
Thanks for the reply! I'm still not sure why it's bad to have named
subroutines. At any rate I cant use anon subs since we have a complicated
reporting subsystem that relies on Perl formulas being eval-ed at runtime,
and these refer to various subro
On Wed, Dec 16, 2009 at 03:15:21PM -0600, Peter wrote:
> Hello Tim,
>
> Thanks for the reply! I'm still not sure why it's bad to have named
> subroutines. At any rate I cant use anon subs since we have a complicated
> reporting subsystem that relies on Perl formulas being eval-ed at runtime,
> and
Hello Tim,
Thanks for the reply! I'm still not sure why it's bad to have named
subroutines. At any rate I cant use anon subs since we have a complicated
reporting subsystem that relies on Perl formulas being eval-ed at runtime,
and these refer to various subroutines.
I have since resolved the is
On Tue, Dec 15, 2009 at 08:35:21AM -0600, Peter wrote:
>After upgrade to 8.4.1 Perl "my" variables are no longer being seen by
> subroutines:
>
> CREATE OR REPLACE FUNCTION global.perl_test()
> RETURNS "varchar" AS
>$BODY$
>my $test="x";
>test();
>return $test;
>s
After upgrade to 8.4.1 Perl "my" variables are no longer being seen by
subroutines:
CREATE OR REPLACE FUNCTION global.perl_test()
RETURNS "varchar" AS
$BODY$
my $test="x";
test();
return $test;
sub test {
elog(NOTICE,"X=".$test);
}
$BODY$
language 'plperlu';
Now
