> 2.0 is in alpha so the same thing applies: focus is on getting it

ready

> for release.
>
> So, I'd say the earliest you can hope for is the version after 2.0,
> which will probably be 3.0.
>
> Others might enlighten you re. timeplan.
>
> Kjell

I've always saw performance as a reason to hold up a build for a while.
Performance isn't a feature, it's a necessity. Look at MySQL for
example. Lacks many features, but kills in performance and is the #1
open source database because of it.

Also, the list of major broken items are still going up and are either
not being fixed for the current user or are being slated to be fixed
in a later version.

Examples of broken items:
1. INSERT INTO TABLEA SELECT FROM TABLEA;
2. DELETE FROM TABLEA WHERE (SELECT FROM TABLEA);
3. Data type coercion of views in 1.5.2.(You have to cast too much.)
4. Data type coercion in general.(You have to cast too much.)
5. READ_COMMITTED Transactions.(still unclear on what should be used
instead of...)
6. 20x slower page loading than PG.
7. There may be others that I missed or don't know about.

Theses things are not features, but item that people moving to
Firebird would expect any SQL database to have.

So my vote would be to stop with the features and fix the database,
for the current users and for new users (1.5.2 and 2.0).

It's hard to convince the people with the money, why they should buy a
support contract with IBPhoenix when you see they are not even fixing
the major issues that currently exist in their database.

I'm getting tired of making excuses for why Firebird/IBPhoenix does
things the way that it does, while other Open Source MGA databases
don't suffer from these issues.

"It the way MGA databases work" isn't going to cut it anymore.

Thanks for letting me vent...