Re: plperl error format vs plpgsql error format vs pgTAP

Поиск
Список
Период
Сортировка
От Kevin Field
Тема Re: plperl error format vs plpgsql error format vs pgTAP
Дата
Msg-id 48f6f438-874e-407d-9c40-fdf7de9db23d@h23g2000vbc.googlegroups.com
обсуждение исходный текст
Ответ на plperl error format vs plpgsql error format vs pgTAP  (Kevin Field <kevinjamesfield@gmail.com>)
Ответы Re: plperl error format vs plpgsql error format vs pgTAP  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On May 28, 3:22 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field <kevinjamesfi...@gmail.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?


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: PostgreSQL Developer meeting minutes up
Следующее
От: Kevin Field
Дата:
Сообщение: Re: plperl error format vs plpgsql error format vs pgTAP