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.


---------------------------(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

Reply via email to