> 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.
>
> Am I missing something?

No, I have used similar approach in Jaybird. The only problem is that
there are only few SQLSTATEs that map nicely to Firebird:

SQL_STATE_INVALID_CON_ATTR "01S00"
SQL_STATE_NO_ROW_AVAIL "01S06"
SQL_STATE_GENERAL_ERROR "HY00"
SQL_STATE_DRIVER_NOT_CAPABLE "HYC00"
SQL_STATE_INVALID_COLUMN "HY02"
SQL_STATE_INVALID_PARAM_TYPE "HY105"
SQL_STATE_INVALID_ARG_VALUE "HY009"
SQL_STATE_WRONG_PARAM_NUM "07001"
SQL_STATE_NO_RESULT_SET "07005"
SQL_STATE_INVALID_CONVERSION "07006"
SQL_STATE_CONNECTION_CLOSED "08003"
SQL_STATE_CONNECTION_FAILURE_IN_TX "08007"
SQL_STATE_COMM_LINK_FAILURE "08S01"
SQL_STATE_INVALID_ESCAPE_SEQ "22025"

At least that's what I was able to map in Jaybird...

Roman