Tom Lane writes:
> 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.
The severity field is useless, because it contains localized text that
cannot be evaluated by a program. Also, neither the severity field nor
the error/notice message distinction is necessarily available in
interfaces that work at a layer above libpq (e.g., embedded SQL).
There is no portable (let alone consistent) way right now to detect
whether a given condition is success, a warning, or an error.
> AFAICS the alternative to misusing error-class SQLSTATEs as warnings is
> that we invent implementation-specific warning codes.
I don't see that as being allowed.
> Is it really worth having two codes for what amounts to the same
> condition?
The same condition shouldn't be a warning in one place and an error in
another. Otherwise it's not really the same condition.
--
Peter Eisentraut [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
