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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
