Re: plpgsql raise - parameters can be expressions - Mailing list pgsql-patches

From Tom Lane
Subject Re: plpgsql raise - parameters can be expressions
Date
Msg-id 21429.1118681805@sss.pgh.pa.us
Whole thread Raw
In response to Re: plpgsql raise - parameters can be expressions  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
Responses Re: plpgsql raise - parameters can be expressions  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
List pgsql-patches
Pavel Stehule <stehule@kix.fsv.cvut.cz> writes:
>> Ideas?

> only RAISE? Without parameters can be used only in block. It's same scope
> like SQLERRM and SQLSTATE.

OK, but what about the other problem --- throwing a non-default SQLSTATE
along with your custom error message?

>   RAISE my_exception; -- named exception; -- no params

Definitely not adequate.  Maybe we could do

    RAISE my_exception, 'format', params;

I think it would be better to do something like

    RAISE ERROR my_exception, 'format', params;

since this won't be ambiguous with the existing variants of RAISE;
without the ERROR keyword it'd be necessary to forbid exception names
from being DEBUG, LOG, etc.

I like your DECLARE syntax better than Oracle's incredibly ugly "pragma"
notation, and we can't expect to be exactly compatible with the pragma
anyway since the pragma is associating the name with an integer code,
which is not what we are going to use.  So that part seems good.

I assume you intend to allow "RAISE ERROR division_by_zero ..." and
"EXCEPTION WHEN my_exception THEN ...", right?  That is, declared
exception names are interchangeable with the predefined ones for
both throwing and catching errors.

> I can use user's exception with default unique value from predefined
> interval too.

I see zero value in that.  The only reason for declaring a specific
user-defined exception code is so you can identify it from elsewhere,
like in your application --- so not knowing which code it's getting
makes it useless.

            regards, tom lane

pgsql-patches by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql raise - parameters can be expressions
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql raise - parameters can (ToDo)