Re: Syntax decisions for pl/pgsql RAISE extension
От | Tom Lane |
---|---|
Тема | Re: Syntax decisions for pl/pgsql RAISE extension |
Дата | |
Msg-id | 25109.1210621628@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Syntax decisions for pl/pgsql RAISE extension ("Pavel Stehule" <pavel.stehule@gmail.com>) |
Ответы |
Re: Syntax decisions for pl/pgsql RAISE extension
|
Список | pgsql-hackers |
"Pavel Stehule" <pavel.stehule@gmail.com> writes: > I like this syntax, but I am not if it's good idea add new similar > statement. I don't know - but maybe it's can be better then extending > RAISE - and way to get consensus. I looked a bit more at the SQL spec. It already defines a <condition information item name> MESSAGE_TEXT, which arguably is what we should use for the primary message item, but that seems unpleasantly long for something that's going to be used in pretty much every SIGNAL command. Also there's a question of whether it's supposed to mean the *complete* message delivered to a client, which would subsume DETAIL, HINT, etc in our scheme. So I'm a bit tempted to stick with MESSAGE, DETAIL, and HINT as the settable options if we go with SQL/PSM-derived syntax. We'd also want LEVEL or something to be able to specify non-ERROR elog levels. Also, as to the re-throw-an-error capability, SQL/PSM defines a RESIGNAL command that does this. I propose implementing only the parameterless variant of this, at least for the time being. (The spec appears to intend that RESIGNAL can override selected fields of the error being re-thrown, which doesn't strike me as a terribly good idea --- you could end up with a completely nonsensical error report.) regards, tom lane
В списке pgsql-hackers по дате отправления: