Hello all!

I would like to propose a new API, isc_sqlstate() for Vulcan that would
return the SQLSTATE information. I have this mostly working within a
playpen, and now is a good time for me to share my design proposal.

I've uploaded the document to uploaded files section of the firebird
architect group. This covers the current SAS implementation, which I
want to replace (you can skip that part), along with the new code. I've
highlighted the parts I wasn't sure about. I also uploaded a spreadsheet
and SQL file which shows my proposed datafill - that's the hard part.

This feature will require changes to the message database. Obviously, we
have to new SQLSTATE information. But there are also a couple of places
where today's error message is ambiguous, and needs to be un-ambiguated
(disambiguated?).

Here's one. We have SQLSTATE 22001, "String data, right-truncated" and
SQLSTATE 22012, "Division by zero". But, we have one Firebird message
that is printed for both of these case:

SQL> recreate table test (c char(5 ) ) ;
SQL> insert into test (c) values ('text123') ;
Statement failed, SQLCODE = -802
arithmetic exception, numeric overflow, or string truncation

SQL> select (1/0) from rdb$database ;

=====================
Statement failed, SQLCODE = -802
arithmetic exception, numeric overflow, or string truncation


Here's a case where we don't generate a specific error, but should. We
should map error below to SQLSTATE 42S21, "Column already exists."

SQL> create table test (i integer) ;
SQL> alter table test add i integer ;
Statement failed, SQLCODE = -607
unsuccessful metadata update
-STORE RDB$RELATION_FIELDS failed
-attempt to store duplicate value (visible to active transactions) in
unique index "RDB$INDEX_15"

Those were the only ones I've seen so far - there are likely more.

I am comfortable integrating what I have (after review) into SF Vulcan.
But, I would like some guidance on the message database changes I
propose.

I think it would be better to make these database changes also to FB2
head. I don't like adding new messages to Vulcan message database only,
since these will likely be forgotten / overwritten when the merge occurs
and the GDSCODEs get out of sync. It is better, I think, to keep FB2 as
the master version of the message database. I've tried to do this in the
past by communicating any proposed message file changes to the team. A
few times Claudio has then helped me by making the necessary change in
FB2+.

If the message database file changse are pushed to FB2, the code changes
could wait until the FB3 timeframe.

I look forward to your response!

-bill