Peter Eisentraut <[EMAIL PROTECTED]> writes:
> In other words, an info, notice, or warning must have a class 00, 01, 02.
I suspect though that the spec is assuming that the SQLSTATE code is the
*only* way for the application to determine whether the message is
success, warning, or error. Since we have other signaling mechanisms
(the severity field, or even more basically the Error/Notice message
type distinction), I'm not convinced we need to be entirely anal about
this division.
AFAICS the alternative to misusing error-class SQLSTATEs as warnings is
that we invent implementation-specific warning codes. Is it really
worth having two codes for what amounts to the same condition?
> However, I noticed several warnings that use codes that are intended for
> errors, for example in portalcmds.c and xact.c.
Several of them are things that probably *ought* to be errors, as you
noted in a later message. I don't recall exactly what other sins I
committed in this area (the whole effort is already becoming a blur ;-)).
We have time to rejigger around the edges though --- I have no objection
to reassigning codes during beta. Once we release it will get harder.
A possibly related sin in the same category is that I think that the
class-40 SQLSTATEs are intended to imply that the server has forcibly
aborted your whole transaction --- not just the current statement, which
is what I think the spec envisions for all the other error classes.
We do not currently make that distinction, but sooner or later we will.
Perhaps we should avoid the class-40 codes and make our own
implementation-dependent codes for deadlock detection and so forth.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
