Re: Syntax decisions for pl/pgsql RAISE extension
От | Tom Lane |
---|---|
Тема | Re: Syntax decisions for pl/pgsql RAISE extension |
Дата | |
Msg-id | 23346.1210615850@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Syntax decisions for pl/pgsql RAISE extension ("Brendan Jurd" <direvus@gmail.com>) |
Ответы |
Re: Syntax decisions for pl/pgsql RAISE extension
|
Список | pgsql-hackers |
"Brendan Jurd" <direvus@gmail.com> writes: > I agree that the % formatting in the RAISE message is weird, but it is > useful. Sure, I'm not proposing removing it. > What would we do if the user specifies a %-formatted message as well > as a MESSAGE option? Throw an error (just like if they specified the same option type twice). > I like "RAISE condition_name", can we support it in conjunction with > the current syntax? That is: > RAISE level [condition] [string literal, [parameter, ...]] [USING > [option = value, ...]] Well, it's sort of a mess because level has to become optional in order to be Oracle-compatible (or PSM-compliant, if Kevin is correct). We could get away with it only if the condition were not allowed to be a string literal, which I guess is tolerable but it's a bit annoying. It would get less annoying if we allowed user-declared exception names. I find the Oracle syntax for those to be spectacularly awful: DECLARE deadlock_detected EXCEPTION; PRAGMA EXCEPTION_INIT(deadlock_detected, -60); but it sounds like SQL/PSM's syntax isn't so bad. I could live with the reported DECLARE condition-name CONDITION FOR SQLSTATE VALUE character-literal However, that's a separate feature and I don't want to get into it as part of the current patch. regards, tom lane
В списке pgsql-hackers по дате отправления: