On May 29, 12:43 pm, Kevin Field wrote:
> On May 29, 11:48 am, Kevin Field wrote:
>
>
>
> > On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
> > > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > > wrote:
> > > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wro
On May 29, 1:04 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field writes:
> > default:
> >elog(ERROR, "unrecognized raise option: %d",
> > opt->opt_type);
> > Should this be changed to:
> > default:
> >ereport(ERROR, (errmsg_internal("u
On May 29, 11:48 am, Kevin Field wrote:
> On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
>
>
> > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > wrote:
> > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
> > >> On May 28, 2009, at 12:53 PM, Kevin Field
Kevin Field writes:
> default:
> elog(ERROR, "unrecognized raise option: %d",
> opt->opt_type);
> Should this be changed to:
> default:
> ereport(ERROR, (errmsg_internal("unrecognized
> raise option: %d",
> opt->opt_type)));
No, we g
On May 29, 11:48 am, Kevin Field wrote:
> On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
>
>
>
> > On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> > wrote:
> > > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
> > >> On May 28, 2009, at 12:53 PM, Kevin Field
On May 29, 11:35 am, robertmh...@gmail.com (Robert Haas) wrote:
> On Fri, May 29, 2009 at 7:59 AM, Kevin Field
> wrote:
> > On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
> >> On May 28, 2009, at 12:53 PM, Kevin Field wrote:
>
> >> >> Can pgTap check for a regex instead if j
On May 29, 2009, at 4:59 AM, Kevin Field wrote:
http://github.com/theory/pgtap/tree/master/
I'm getting a new version ready to release as I type.
Thanks, great to know. :) Although, I do think changing plperl is
the more proper option, so I'm going to try there first...
I added `throws_
Kevin Field wrote:
On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
On May 28, 2009, at 12:53 PM, Kevin Field wrote:
Can pgTap check for a regex instead if just a string?
That's the other option, if the pgTAP author is willing...if the
SQLSTATE thing doe
On Fri, May 29, 2009 at 7:59 AM, Kevin Field wrote:
> On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
>> On May 28, 2009, at 12:53 PM, Kevin Field wrote:
>>
>> >> Can pgTap check for a regex instead if just a string?
>>
>> > That's the other option, if the pgTAP author is will
On May 28, 5:19 pm, da...@kineticode.com ("David E. Wheeler") wrote:
> On May 28, 2009, at 12:53 PM, Kevin Field wrote:
>
> >> Can pgTap check for a regex instead if just a string?
>
> > That's the other option, if the pgTAP author is willing...if the
> > SQLSTATE thing doesn't work out I guess we'
On May 28, 2009, at 12:53 PM, Kevin Field wrote:
Can pgTap check for a regex instead if just a string?
That's the other option, if the pgTAP author is willing...if the
SQLSTATE thing doesn't work out I guess we'll have to go down that
road.
Patches welcome. ;-)
http://github.com/theory/pg
On May 28, 2009, at 12:22 PM, Tom Lane wrote:
What you need is a test that looks at the SQLSTATE code, and little
if anything else.
Yes, and throws_ok() supports that:
SELECT throws_ok( 'SELECT 1 / 0', '22012' );
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Kevin Field writes:
> I wanted to use the SQLSTATE code, but it's always XX000. If there
> were some way to set it when calling elog()
ereport?
http://developer.postgresql.org/pgdocs/postgres/error-message-reporting.html
At the plpgsql level, since 8.4 you can specify a SQLSTATE in RAISE.
AFAI
On May 28, 3:28 pm, and...@dunslane.net (Andrew Dunstan) wrote:
> 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 n
On May 28, 3:22 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kevin Field 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
> >
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
Kevin Field 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
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 t
18 matches
Mail list logo
