Re: plperl error format vs plpgsql error format vs pgTAP - Mailing list pgsql-hackers

From Kevin Field
Subject Re: plperl error format vs plpgsql error format vs pgTAP
Date
Msg-id a717d99b-03e3-4828-90aa-b3974b59c413@j12g2000vbl.googlegroups.com
Whole thread Raw
In response to plperl error format vs plpgsql error format vs pgTAP  (Kevin Field <kevinjamesfield@gmail.com>)
Responses Re: plperl error format vs plpgsql error format vs pgTAP  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On May 29, 11:48 am, Kevin Field <kevinjamesfi...@gmail.com> wrote:
> On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
>
>
> > On Fri, May 29, 2009 at 7:59 AM, Kevin Field <kevinjamesfi...@gmail.com> wrote:
> > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
> > >> On May 28, 2009, at 12:53 PM, Kevin Field wrote:
>
> > >> >> Can pgTap check for a regex instead if just a string?
>
> > >> > That's the other option, if the pgTAP author is willing...if the
> > >> > SQLSTATE thing doesn't work out I guess we'll have to go down that
> > >> > road.
>
> > >> Patches welcome. ;-)
>
> > >>    http://github.com/theory/pgtap/tree/master/
>
> > >> I'm getting a new version ready to release as I type.
>
> > > Thanks, great to know.  :)  Although, I do think changing plperl is
> > > the more proper option, so I'm going to try there first...
>
> > It seems to me that removing line numbers from PL/perl error messages
> > is not a good solution to anything.  Line numbers are extremely useful
> > for debugging purposes, and getting rid of them because one particular
> > testing framework doesn't know how to use regular expressions is
> > solving the wrong problem.
>
> You're right, but that's not what I'm proposing...
>
> > I'm also a bit confused because your original post had a line number
> > in the PL/pgsql output, too, just formatted slightly differently.  Why
> > doesn't that one cause a problem?
>
> The difference is, in PL/pgsql they're in the CONTEXT: line, whereas
> in plperl they're in the error line.  This is inconsistent; if we fix
> it, we don't need to add kludge to pgTAP.
>
> But later in the thread the desired fix became not changing perl but
> instead making a way to report error codes from plperl, which is what
> I'm attempting to do with my rusty C skills soon.  plperl should have
> ereport() *anyway*, as I believe Tom had insinuated.

BTW, I noticed in exec_stmt_raise() in src/pl/plpgsql/src/pl_exec.c
that the comment still says "throw it with elog()" rather than "ereport
()" even though ereport() is used in all places but one in the
function:

default:            elog(ERROR, "unrecognized raise option: %d", opt->opt_type);

Should this be changed to:

default:            ereport(ERROR, (errmsg_internal("unrecognized raise option: %d",
opt->opt_type)));

...along with the comment?


pgsql-hackers by date:

Previous
From: Kevin Field
Date:
Subject: Re: plperl error format vs plpgsql error format vs pgTAP
Next
From: Alvaro Herrera
Date:
Subject: Re: PostgreSQL Developer meeting minutes up