On Thursday 13 March 2003 20:51, Tom Lane wrote:
> (Or, protocol upgrade phase 1...)
>
> After digging through our many past discussions of what to do with error
> messages, I have put together the following first-cut proposal. Fire at
> will...
>
>
> Objective
> ---------
>
> The basic objective here is to divide error reports into multiple
> fields, and in particular to include an "error code" field that gives
> applications a stable value to test against when they're trying to find
> out what went wrong. (I am not spending much space in this proposal on
> the question of exactly what set of error codes we ought to have, but
> that comes soon.) Peter Eisentraut argued cogently awhile back that the
> error codes ought not be hard-wired to specific error message texts,
> so this proposal treats them as separate entities.
>
>
What about user messages ?
If I remember correct, MSSQL had a system catalog table with formated error
messages, and it was possible to raise error with error number and it's
parameters. It can be very useful when you must raise same error from
different places in the code. It is very useful when you need to translate
error messages to another language for example. I think that there was a
range of error numbers reserved for user error messages.
Maybe even system messages can be stored in same way.
OK, there is problem how to raise an error if you can sp_connect and get the
error message (because an error is in sp_connect) ???
Just an Idea (from M$) !
