From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: plpgsql raise - parameters can be expressions |
Date: | 2005-06-15 07:46:35 |
Message-ID: | 42AFDCDB.2030400@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I would also expect that matching is by SQLSTATE, that is if I write
>
> DECLARE foo EXCEPTION = '12345';
> ...
> RAISE ERROR foo, ...;
BTW, is there any value in a separate "EXCEPTION" type? ISTM that an
exception is just a SQLSTATE, which is in turn just a string. A separate
exception type does simplify the parsing of RAISE, but I wonder if it
would be useful to be able to also allow specifying the SQLSTATE code as
a string literal.
> I think we are better off defining exception names as SQLSTATEs and
> nothing else.
That seems the right way to go to me.
> Well, can we get away with making the syntax be
>
> RAISE level [ exception_name , ] format_string [ , parameters ] ;
>
> where "level" is one of the already-defined level keywords?
I think we can. I don't see the point of inventing a new RAISE level for
exceptions with a custom SQLSTATE. For one thing, it would be useful to
be able to specify a custom SQLSTATE for a RAISE WARNING.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-06-15 07:47:27 | Re: hash join: probe both inputs first |
Previous Message | Andreas Pflug | 2005-06-15 06:32:28 | Re: dbsize backend integration |