Re: SQLSTATEs for warnings

Tom Lane writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> 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 peter_e(at)gmx(dot)net