> Let's decide, what is our database - schema or catalog? On the one hand,
> looking at standard it seems it's sooner catalog rather then schema (for
> example, it has something like required INFORMATION_SCHEMA, our RDB$*
> tables). On the other hand, in our SQL 'CREATE DATABASE' and 'CREATE SCHEMA'
> are synonyms.

For me Firebird database is a catalog with only one schema there.
Hopefully it will be extended to handle multiple schemas.

>>> Next, let's look at it from releases POV. Modifications, required in
>>> optimizer to make it use external datasources, are far not trivial (Arno,
>>> Vlad, correct me if I'm wrong here). Therefore feature can't be planned
>>> for something earlier then first version AFTER merged 3.0 version. And
>>> it's quite real to prepare requirements for API changes up to that time.
>> Don't know... at the moment I tend to say that it won't work. Look on
>> our 2.1 release. It includes everything that did not fit the 2.0 plan,
>> but was already implemented. We have some delay here as well, but in
>> general things look pretty nice. The 3.0 is also based on something that
>> does already exist (both Vulcan and 2.1 are real, however there will be
>> tons of things to fix). Planing API change for 3+ version without having
>> it already implemented, from my POV, won't work (remember, we're already
>> in 3.0 time - the 2.1 is done). Therefore, at best it will make it into
>> 3++, and that is end of 2009-2010.
>
> Seems to be so, but anyway we can't add new features too both 2.1 and 3.0. Or
> we will never release.

The 2.1 and 3.0 are closed for features, that is clear.

I was thinking about 3+ version with external data sources (at least
"external datasources lite") and full-blown version as in current RFC in
3++ version.

Roman