On Wednesday 01 August 2007 17:33, Roman Rokytskyy wrote:

> Yup... only that external datasources is one of the very demanded
> features, but most people can live with 31-byte long identifiers. I'm
> inclined to put such dependency on our roadmap at the moment.
>
> Anyway, I'd like to hear list of problems with ASA's approach to
> external tables, since it is an alternative approach to Vlad's and does
> not require XSQLDA version change and therefore can be implemented with
> current API.

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>. On the other hand I do not see
something similiar to EXTERNAL DATA SOURCE in CREATE TABLE:
<table definition> ::=
CREATE [ { GLOBAL | LOCAL } TEMPORARY ] TABLE <table name>
<table element list>
[ ON COMMIT { DELETE | PRESERVE } ROWS ]
While we are trying to be as close to standard as possible in many aspects,
why add non-standard extensions when similiar standard-compliant things are
present? 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?

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.