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
|
Список | 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 по дате отправления: