Re: plperl error format vs plpgsql error format vs pgTAP

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Kevin Field <kevinjamesfield(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: plperl error format vs plpgsql error format vs pgTAP
Date: 2009-05-28 19:28:40
Message-ID: 4A1EE5E8.2010402@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-05-28 19:32:30 Re: search_path vs extensions
Previous Message Tom Lane 2009-05-28 19:22:29 Re: plperl error format vs plpgsql error format vs pgTAP