Thread: Assignment scheme for implementation-defined error codes?

Assignment scheme for implementation-defined error codes?

From
Peter Eisentraut
Date:
I'm currently fixing up ecpg for the new error codes.  (ecpg was doing
string comparisons to detect certain failure conditions, which no longer
works, so this is a must-fix.)  Many of the failure conditions that ecpg
detects explicitly can be mapped to SQLSTATE codes that are defined in the
standard or have been assigned for use by the backend.  Some codes,
however, will end up being specific to ecpg.  I'm wondering what kind of
scheme we should use to allow clients to reserve some SQLSTATE codes for
their own use.

The errors I'm currently looking at can be thought of as "internal
errors", so should I be using the class XX, or maybe XY as internal error
on the client side, or maybe YE as internal error on the client side in
ecpg (so YL could be libpq, YO the ODBC driver, etc.)?

What about creating client-specific subclasses of existing classes?

Is the DB2 SQLSTATE reference, where some codes were apparently taken
from, available somewhere?  (A web search doesn't show anything useful.)

-- 
Peter Eisentraut   peter_e@gmx.net


Re: Assignment scheme for implementation-defined error codes?

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> ... I'm wondering what kind of
> scheme we should use to allow clients to reserve some SQLSTATE codes for
> their own use.

> The errors I'm currently looking at can be thought of as "internal
> errors", so should I be using the class XX, or maybe XY as internal error
> on the client side, or maybe YE as internal error on the client side in
> ecpg (so YL could be libpq, YO the ODBC driver, etc.)?

It seems reasonable to reserve Yxxxx for client-side internal errors,
with as you suggest the second character used to identify a particular
client library.

Note also that there are several standard SQLSTATEs that appear to be
intended for client-side use, such as
ERRCODE_SQLSERVER_REJECTED_ESTABLISHMENT_OF_SQLCONNECTION

> What about creating client-specific subclasses of existing classes?

Again we could go with reserving the Y prefix, although the namespace is
getting rather tight there --- if we use the next character to
distinguish different clients, there's only one character left for the
individual errors.  Perhaps a dozen or so per client will be enough.

> Is the DB2 SQLSTATE reference, where some codes were apparently taken
> from, available somewhere?  (A web search doesn't show anything useful.)

You need to google for the "DB2 Message Reference"; in recent editions
the SQLSTATE stuff is in Volume 2, Chapter 3.  There are complete sets
of DB2 manuals available as PDFs at www.ibm.com.  I don't have a record
of the exact URL I found it at, but I've been using a PDF of the message
reference manual for DB2 Version 8.
        regards, tom lane