Re: plpgsql raise - parameters can be expressions
От | Tom Lane |
---|---|
Тема | Re: plpgsql raise - parameters can be expressions |
Дата | |
Msg-id | 21429.1118681805@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plpgsql raise - parameters can be expressions (Pavel Stehule <stehule@kix.fsv.cvut.cz>) |
Ответы |
Re: plpgsql raise - parameters can be expressions
|
Список | 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 по дате отправления: