>Let me get this straight. You are willing to create the shadow

fields and

>write the triggers to implement a solution in FB/IB but you are not

willing to

>do it when the theoretical time comes to move the database to

another RDBMS

>because you will be embarrassed? Does this really make sense?

No. I would not be willing to create the shadow fields. Without case-
insensitive indexing, I wouldn't be willing to use Firebird at all.
The whole point of my post was that I considered the various hacks
that were necessary to get case-insensitivity to work on a Linux box
to be unportable because it bound my code (either client-side or
server-side) tightly to the shortcomings of Firebird. In most
databases (Oracle, MSSQL, PostgreSQL, MySQL, etc.) you can add,
modify and delete indexes without recoding anything. In Firebird, if
I wanted to add an case-insensitive index to a table, I would have to
alter the table to add additional indexing columns and modify a
trigger. This seems a bit unwieldy if you are accustomed to other
databases.

Also, I never said I would be embarrassed. I said the Oracle DBA's
would laugh at me when I explained to them all the hoops I had to
jump through to get an index to work. They'd ask "Why didn't you just
use PostgreSQL"? Programmers who would look at a Firebird-designed
database implemented on Oracle would be confused as to why these
triggers were duplicating data in upper case to another field. No
other database that I know of accomplishes case-insensitive indexing
this way.

If I knew a database would live forever on Firebird and I would
always use Firebird for future work, I might be willing to overlook
this particular shortcoming. But if there's even a remote chance that
I might have to move a project to a different backend, then I would
want to find use a database that was more compatable with the other
databases out there.