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?

> Telling true, use of ASA approach here just in order to fit new
> features into old API looks like a short-term hack here. Could it have some
> more serious advantages?

It is a short-term hack, but the hack that can be removed later in a
compatible way. That's the only justification for it.

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

Roman