Re: the case for machine-readable error fields

Sam Mason <sam@samason.me.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