Re: the case for machine-readable error fields

Sam Mason <sam@samason.me.uk> wrote: 
> Not sure if overloading SQLSTATE is the right way of doing this is
> it?  It already has things like 23514 for a check violation and any
> other client code relying in this would break if it started getting
> different things back.
If that's the standard SQLSTATE, I agree -- it suggests a need for
some user-controllable field which could be set to a value to indicate
a particular problem.  Does the standard have anything like that, or
would that be an extension?
> p.s. I think you were agreeing with everything else I was saying,
> even if I didn't explain myself well enough for you to understand
> me!
It's good to see convergence, then.  Sorry I misunderstood.
-Kevin