Tom,

> 1. Lack of Internal set of system functions automatically available to
> all databases. (These would be considered seperate, and *in addition*
> to the good UDF support)

Agreed, there have been higher priority items to be addressed before we
tackled this.

> 2. The ludicrous situation of having to create 'shadow' columns +
> BI/BU triggers in order to provide case-insensitive searches.

Firebird v2.0 allows for indexes to be defined based on expressions.
Thus you will be able to define an index on "UPPER( Field_NAME)" and
have the system use the index as appropriate.

> 3. Domains *used throughout entire system* would be great.

This has been discussed and there are a number of semantic issues
related to using Domains.

Domains support a larger definition than 'simple' data type, such as
default and check/constraints. Are these 'extended properties' to be
applied each time a SP is called?

Additionally, Domains can be ALTERed. What is the impact of ALTERing a
Domain on the related SPs?

> 4. Views where you don't have to specify return datatypes.

Please provide an example.

> 5. The ability to turn off the 'bitmapping' of multiple indexes.

Since you have already responded separately that this is a performance
related issue, I will point out that v2.0 has:

- a completely new ODS (On Disk Structure) for indexes, which
- implements a new compression algorithm
- significantly reduces the overhead of poorly selective indexes
(a lot of duplicates)
- increases the max size of an index
- adds selectivity for segments of multi segment indexes

- a significant revision to the optimizer

With all of this, index handling and performance is at least an order of
magnitude better (from my own testing)

> 7. Export DUMP options to SQL statements, XML, etc

There are already a number of third-party tools (free) which do this.
Why would the project 're-invent the wheel'?


Sean