Dmitry Yemanov wrote:

> "Tom Cole" <tom.cole@...> wrote:
>
>> What is the current state of thinking on support for SQLSTATE in
>> Firebird/Vulcan? Since I work on an application that must be able
>> to connect to multiple databases (including Vulcan!), I think that
>> a SQLSTATE value that is part of the return status block is very
>> useful in attempting to consolidate programmatic response to error states.
>>
>> I imagine we'd want something like a new return code stack entry of
>> isc_arg_sqlstate which takes as it's argument a pointer to a
>> five-character string which contains the SQLSTATE value.
>>
>
> AFAIU, this could (should?) be achieved via a mapping table between
> GDSCODE's and SQLSTATE's (similarly to how SQLCODE's are handled) + one new
> API function (fb_sqlstate?). This way, GDSCODE's are still the primary error
> ids and nothing in the engine needs to be modified. The client passes the
> status vector to fb_sqlstate() and gets SQLSTATE value. PSQL code may be
> extended to support WHEN SQLSTATE <value> construct.
>
>

I think Dmitry is right. Everything needed should be available in the
status vector and the client API. It may be necessary to beef up
context on some engine errors, but most of the work should be handled
clientside.

Oh, and thanks for the pointer to MySQL error messages. The error codes
available in the storage engine vastly more restricted.