Thread: sqlstate 22P06 is a warning in an error's clothing

The server logs "WARNING: nonstandard use of \\ in a string literal at
character 44", but the message comes with sqlstate code 22P06, which is
in an error class ("Data exception"). So my application thinks it's an
error, and is unhappy.

Since the sqlstate code is the only useful machine-readable field in the
error message, it is rather unfortunate for it to not reflect the actual
failure status.

Of course, I can special-case code 22P06 in my code and treat it as a
warning (which is what I'll have to do anyway, for 8.2 compatibility),
but I think:

- the warning should be assigned a different code in the 01 class.
- The 22P06 code should be "retired", i.e. not reassigned to a real error in future (because then any bug workaround
similarto mine would break).
 

Thoughts?

-- ams

Abhijit Menon-Sen <ams@oryx.com> writes:
> The server logs "WARNING: nonstandard use of \\ in a string literal at
> character 44", but the message comes with sqlstate code 22P06, which is
> in an error class ("Data exception"). So my application thinks it's an
> error, and is unhappy.

If you are trying to tell errors from warnings, why are you not looking
first at PQresultStatus (or equivalent in other client APIs)?

I think reassigning the message to another sqlstate will break more
clients than it fixes.  It's not the only problematic case either, eg
           ereport(NOTICE,                   (errcode(ERRCODE_NAME_TOO_LONG),                    errmsg("identifier
\"%s\"will be truncated to \"%.*s\"",                           ident, len, ident)));
 
        regards, tom lane