> 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
