On Thursday 02 August 2007 11:57, Roman Rokytskyy wrote:

> Alex,
>
> > Well, first question - how does it look from SQL standard POV? With
> > slightly modified (avoid '@' in favour of '.') Vlad's suggestion we are
> > getting quite close to it: <schema name>.<table name>.
>
> I'm also against using datasource as schema, since they aren't schemas.
> In the worst case they can be considered as "catalogs". Is there
> something like it in SQL standard?

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.

> > 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.