Re: Syntax decisions for pl/pgsql RAISE extension
От | Pavel Stehule |
---|---|
Тема | Re: Syntax decisions for pl/pgsql RAISE extension |
Дата | |
Msg-id | 162867790805122053i745e2c8ap4244b900a5b77c99@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Syntax decisions for pl/pgsql RAISE extension (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Syntax decisions for pl/pgsql RAISE extension
|
Список | pgsql-hackers |
2008/5/12 Tom Lane <tgl@sss.pgh.pa.us>: > "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. > I agree > 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.) > ok > regards, tom lane > who write this patch? Pavel
В списке pgsql-hackers по дате отправления: