Skip site navigation (1) Skip section navigation (2)

Re: plperl error format vs plpgsql error format vs pgTAP

From: Kevin Field <kevinjamesfield(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plperl error format vs plpgsql error format vs pgTAP
Date: 2009-05-28 19:53:25
Message-ID: 63416f1b-dc02-4f19-971d-f3e7a92604af@s28g2000vbp.googlegroups.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On May 28, 3:28 pm, and(dot)(dot)(dot)(at)dunslane(dot)net (Andrew Dunstan) wrote:
> Kevin Field wrote:
> > I use pgTAP to make sure my functions produce the correct errors using
> > throws_ok().  So when I get an error from a plpgsql function, it looks
> > like this:
>
> > ERROR:  upper bound of FOR loop cannot be null
> > CONTEXT:  PL/pgSQL function "foo" line 35 at FOR with integer loop
> > variable
>
> > ...which I can then test using throws_ok by giving it the string
> > 'upper bound of FOR loop cannot be null'.  However, in a plperl
> > function, errors come out in this format:
>
> > error from Perl function "check_no_loop": Loops not allowed!  Node 1
> > cannot be part of node 3 at line 13.
>
> > Unfortunately, I can't test for this without including the line
> > number, which means that changing any plperl function that I have such
> > a test for pretty much guarantees that I'll need to change the test to
> > reflect the new line numbers the errors would be thrown from in the
> > function.
>
> > Is it possible to unify the error reporting format, so pgTAP can test
> > them without needing line numbers from plperl functions?
>
> This is under perl's control, not ours. The perl docco says:
>
>     If the last element of LIST does not end in a newline, the current
>     script line number and input line number (if any) are also printed
>     and a newline is supplied.
>
> 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.

In response to

Responses

pgsql-hackers by date

Next:From: Aidan Van DykDate: 2009-05-28 19:56:14
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Kevin FieldDate: 2009-05-28 19:51:38
Subject: Re: plperl error format vs plpgsql error format vs pgTAP

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group