Sam Mason <sam(at)samason(dot)me(dot)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