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:51:38 |
Message-ID: | 48f6f438-874e-407d-9c40-fdf7de9db23d@h23g2000vbc.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On May 28, 3:22 pm, t(dot)(dot)(dot)(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) wrote:
> Kevin Field <kevinjamesfi(dot)(dot)(dot)(at)gmail(dot)com> writes:
> > 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'.
>
> Surely, this is a completely brain-dead approach to testing errors
> in the first place ... what will happen in a localized installation?
>
> What you need is a test that looks at the SQLSTATE code, and little
> if anything else.
There won't be any localized installations.
I wanted to use the SQLSTATE code, but it's always XX000. If there
were some way to set it when calling elog() so I knew the right error
was being reached, that would be a great option. Is that something
under the control of PostgreSQL?
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Field | 2009-05-28 19:53:25 | Re: plperl error format vs plpgsql error format vs pgTAP |
Previous Message | Tom Lane | 2009-05-28 19:33:15 | Re: search_path vs extensions |