Michael Fuhr said: > On Tue, Aug 23, 2005 at 10:30:51PM -0600, Michael Fuhr wrote: >> Global symbol "$x" requires explicit package name at (eval 3) line 1. >> >> If I'm reading the Perl source code correctly (pp_ctl.c), the number >> following "eval" comes from a variable named PL_evalseq that's >> incremented each time it appears in one of these messages. It looks >> like we'd have to munge the error message to get rid of that. > > Hmmm...tests suggest that we might be able to munge $@ in the > mk*safefunc functions. That is, instead of doing > > return eval($stuff); > > we might be able to do > > my $retval = eval($stuff); > $@ =~ s/ \(eval \d+\) / /g if $@; > return $retval; > > That would convert messages like > > Global symbol "$x" requires explicit package name at (eval 3) line 1. > > into > > Global symbol "$x" requires explicit package name at line 1. > > Is that what you're looking for? So far I've done only simple tests in > standalone embedded Perl programs, so I don't know if this approach > would work in PL/Perl or have unintended effects.
It would probably be more efficient and less convoluted to munge this in a __DIE__ handler. The we wouldn't need the extra level of eval. e.g. $SIG{__DIE__} = sub { my $msg = $_[0]; $msg =~ s/\(eval \d+\) //; die $msg; }; cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match