> 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.
I can define more user's exceptions. And every can have own message text. It's personal preference. I prefere one exception, one parametrized message text. It's not important on procedure level. But If can be possible define exceptions for schema, then I can share message texts. > > 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. Yes, it's can be source of errors. But I can check it in compile time (not now, or after apply patch (if will be). > > 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. > my ideas are only proposal. Nothing more. What I think is important o using expr in raise params o set SQLSTATE for better diagnostic o raising system's exceptions all next is unnecessary luxus. But the idea EXCEPTION's variable is good, and can be easy evolved. Regards Pavel Stehule ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]