Subject | Re: [Firebird-Architect] Bi-directional indexes |
---|---|
Author | buppcpp@yahoo.com |
Post date | 2005-06-27T09:35:47Z |
How about instead of adding bi-directional indexes you fix some of the
existing bugs in Firebird and add the things people have been asking for
where there is no realistic work around.
Like...
1. INSERT INTO MYTABLE_A (SELECT FROM MYTABLE_A WHERE ...) 2. Values to
Function coercion is need far too much. I.e.. DECIMAL(15,2) has to be CAST
to DOUBLE PRECISION. Should happen automatically.
3. Multiple instances of FB running on the same machine.
4. Making the Service API available thru SQL or Stored Procedure.
5. Canceling run away queries.
6. Add a TIMEOUT for long running queries.
7. Database clustering.
8. Stop making internal functions with "FROM" and "TO" in them (i.e.
SUBSTRING, EXTRACT...). I don't thinks it's very compatible with other
database. (Just throwing this one in) :)
Don't get me wrong, Bi-Indexes would be nice, but a workaround already
exist, so your customer are not without a "life-jacket".
"Most" of the issues above (and others) become an a "sink-or-swim" issue.
Because without them your database is useless and in many instances, I would
think, much too incompatible or limited in comparison to the database they
are trying to switch from, so they decide to stay where there at, or move on
to PostgresSQL.
Thanks
[Non-text portions of this message have been removed]
existing bugs in Firebird and add the things people have been asking for
where there is no realistic work around.
Like...
1. INSERT INTO MYTABLE_A (SELECT FROM MYTABLE_A WHERE ...) 2. Values to
Function coercion is need far too much. I.e.. DECIMAL(15,2) has to be CAST
to DOUBLE PRECISION. Should happen automatically.
3. Multiple instances of FB running on the same machine.
4. Making the Service API available thru SQL or Stored Procedure.
5. Canceling run away queries.
6. Add a TIMEOUT for long running queries.
7. Database clustering.
8. Stop making internal functions with "FROM" and "TO" in them (i.e.
SUBSTRING, EXTRACT...). I don't thinks it's very compatible with other
database. (Just throwing this one in) :)
Don't get me wrong, Bi-Indexes would be nice, but a workaround already
exist, so your customer are not without a "life-jacket".
"Most" of the issues above (and others) become an a "sink-or-swim" issue.
Because without them your database is useless and in many instances, I would
think, much too incompatible or limited in comparison to the database they
are trying to switch from, so they decide to stay where there at, or move on
to PostgresSQL.
Thanks
[Non-text portions of this message have been removed]