Re: PL/Perl regression tests with use_strict - Mailing list pgsql-patches

From Michael Fuhr
Subject Re: PL/Perl regression tests with use_strict
Date
Msg-id 20050824043051.GA33460@winnie.fuhr.org
Whole thread Raw
In response to Re: PL/Perl regression tests with use_strict  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/Perl regression tests with use_strict  (Michael Fuhr <mike@fuhr.org>)
List pgsql-patches
On Tue, Aug 23, 2005 at 11:58:25PM -0400, Tom Lane wrote:
> Michael Fuhr <mike@fuhr.org> writes:
> > Here's an updated version of the PL/Perl regression test patch that
> > works with Andrew Dunstan's strict mode patch, both when use_strict
> > is enabled and when it's disabled.  The variant of plperl_elog.out
> > is no longer needed.
>
> Actually, the main reason I didn't apply the prior version right
> away was that the variant .out file was bugging me.  Why does the
> error report contain a line number that's dependent on implementation
> internals in the first place?  Changing it to a different number
> doesn't seem like an improvement; can't we get rid of that entirely?

Actually, I just noticed that the varying number isn't a line number
but rather a sequence number.  Example:

% cat foo
#!/usr/bin/perl
use strict;
use warnings;
my $code = '$x = 123;';
eval $code; print $@;
eval $code; print $@;
eval $code; print $@;

% ./foo
Global symbol "$x" requires explicit package name at (eval 1) line 1.
Global symbol "$x" requires explicit package name at (eval 2) line 1.
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.

--
Michael Fuhr

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: plperl strict mode and associated fixes
Next
From: Michael Fuhr
Date:
Subject: Re: PL/Perl regression tests with use_strict