I'm not qualified to have an opinion about what constitutes a critical compatibility issue between Firebird versions, but I would think there are implications to changing the general case for a documented return code, aren't there? Or do FB's clients/consumers tend not to make specific decisions about errors based on _specific_ return codes?

It seems like there are two choices:

1. Changing the return code messaging, by introducing new return codes to augment the isc_arith_except ( which could be reserved for overflow and underflow conditions in their many forms) like the following:

isc_arith_zerodiv
isc_string_trunc


2. Alternatively, since we already return a vector of additional data, we could simply add the above items to the vector as ancillary data. This would presumably not change the "primary return code" for the entry points, but would allow someone post-processing the vector to get additional context to choose a proper SQLSTATE. If this route was chosen, I'd prefer to add an explicit additional state for underflow/overflow like isc_arith_overflow or something similar.


Ann W. Harrison wrote:

>
> Tom Cole wrote:
> ...
>> Here's an example of a problematic error: isc_arith_except.
>
> Which we ought to fix in the general case rather than adding a
> second error handling mechanism.

- Tom