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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
