Re: plpgsql raise - parameters can (ToDo)
От | Tom Lane |
---|---|
Тема | Re: plpgsql raise - parameters can (ToDo) |
Дата | |
Msg-id | 21548.1118682430@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plpgsql raise - parameters can (ToDo) (Pavel Stehule <stehule@kix.fsv.cvut.cz>) |
Ответы |
Re: plpgsql raise - parameters can (ToDo)
|
Список | pgsql-patches |
Pavel Stehule <stehule@kix.fsv.cvut.cz> writes: > declare myexcept exception = 'xxxxx'; > begin; > assoc(myexcept, 'my message % % %'); > raise myexcept, param1, param2, ... Our experience in writing the backend is that hard-wiring a single error message text for a SQLSTATE code is the wrong thing. The SQLSTATE codes are relatively coarse-grained (which is usually the right thing from the perspective of an application trying to match a SQLSTATE) and there is very often room for the text message to give more detail than the SQLSTATE alone conveys. Also, the above seems highly error prone to me since it decouples the format string from the parameters. This is even worse for built-in exception codes since the writer of a plpgsql function shouldn't assume that he knows exactly what % parameters a built-in exception's format string would use. So for all these reasons, I think that only the SQLSTATE should be associated with the exception name. The format string should be part of the RAISE command. regards, tom lane
В списке pgsql-patches по дате отправления: