Re: the case for machine-readable error fields

Sam Mason <sam(at)samason(dot)me(dot)uk> wrote:

> It just looks like a fixed set of numbers for a fixed set of
> conditions, can't find any canonical definition about what it's
> really for though.

Sorry, I'm familiar with the SQLSTATE's role in the spec, I just
wasn't sure how specific they got in their table of standard values
regarding particular constraints. From the spec:

"The character string value returned in an SQLSTATE parameter
comprises a 2-character class value followed by a 3-character subclass
value, each with an implementation-defined character set that has a
one-octet character encoding form and is restricted to <digit>s and
<simple Latin upper case letter>s. Table 32, *SQLSTATE class and
subclass values*, specifies the class value for each condition and
the
subclass value or values for each class value."

and:

"If a subclass value is not specified for a condition, then either
subclass '000' or an implementation-defined subclass is returned."

>From the table, the 23xxx series is for integrity constraint
violations, but they appear not to have gotten too specific about
breaking that down; thereby leaving it as an implementation choice:

integrity constraint violation 23
(no subclass) 000
restrict violation 001

Anyway, it was a bad suggestion that we provide a way to specify a
SQLSTATE to use for a constraint failure. I do think that some field
which could be used for that purpose would be good. Preferably
something which could be specified in the declaration of the
constraint.

-Kevin