Re: Practical sets of SQLSTATE values?

Tom Lane writes:

> 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.

In my mind, distinct error codes are only useful if the application can
react differently to the condition. Hence, "no such function" can be
equated to "no such <anything>" or a general "syntax error", because the
action of the application in all those cases is likely the same (perhaps
show error text to user and make him fix the command). Similarly, "out of
disk space" can be put into a general "internal server error" class
because in all those cases the action is the same (show error text to
administrator and make him fix the problem). How this extends to "invalid
time zone displacement value" is a little beyond my reach right now, but
in general we should be able to get away with relatively few distinct
error codes.

--
Peter Eisentraut peter_e(at)gmx(dot)net