> 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.

Pavel Stehule

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to