Practical sets of SQLSTATE values? - Mailing list pgsql-hackers

From Tom Lane
Subject Practical sets of SQLSTATE values?
Date
Msg-id 9033.1054301220@sss.pgh.pa.us
Whole thread Raw
Responses Re: Practical sets of SQLSTATE values?  (Rod Taylor <rbt@rbt.ca>)
Re: Practical sets of SQLSTATE values?  (Joe Conway <mail@joeconway.com>)
Re: Practical sets of SQLSTATE values?  (Jeff <threshar@torgo.978.org>)
Re: Practical sets of SQLSTATE values?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
I've been starting to look at assigning SQLSTATE values to all the
backend elog() calls, and have realized that the set of values defined
by the spec is very, how you say, uneven.  They have conditions as
specific as "data exception/invalid time zone displacement value"
(22009) and yet nothing for cases as obvious as "no such function"
or "out of disk space".  We're going to need a lot of implementation-
defined SQLSTATE codes if we want the facility to be as useful as it
should be.

What do other DBMSes do about this?  Seems like it would make sense to
borrow as many SQLSTATE codes as we can from Oracle or DB2 or some other
big player ... especially if there's any commonality in their
extensions.  Anyone have lists of implementation-defined SQLSTATEs for
the big commercial DBs?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Lamar Owen
Date:
Subject: Re: No more RH7.3 RPMs?
Next
From: Rod Taylor
Date:
Subject: Re: Practical sets of SQLSTATE values?