> >> How do you propose to handle metadata and system tables? Existing tools
> >> are going to expect that RDB$RELATIONS, RDB$FIELDS, and
> >> RDB$RELATION_FIELDS are appropriately populated?
> >>
> >
> > At my understanding, existing tools expect correctly filled SQLDA after
> > isc_dsql_prepare call. I see no reason for tool makers to expect stored
> > metadata describing external objects.
> >
> The preparation a query, yes. But intelligent tools need metadata like
> table and field names. Either they go through ODBC or JDBC and get
> pseudo system result sets (you should take a look at the ODBC driver to
> see how this is done) or go directly at the OSRI system tables.

Is ODBC\JDBC spec require to return such info about external objects ?

May be some standard requires that DBMS must contain external objects
descriptions in its local information schema ? What standard ? What objects it
must contain ? All possible ?

> In either case, you will need to merge remote metadata into the local metadata.

I will merge it by only...

> There are at least two ways to handle this. One is to populate local
> system tables at the remote create table command time. This has a
> potential problem of version skew. Another way is to fetch remote
> metadata on reference to local system tables. This will have a
> noticeable performance hit. A third scheme is to fetch on first
> reference and cache locally.

...by this (3rd) way

> This is less of a performance hit, but
> still has a version skew problem. Whatever the scheme, however, you
> have to solve the problem somehow or break most tools and the ODBC and
> JDBC drivers.

May i ask our ODBC\JDBC developers if it is required to return information
from external schemas ? Roman ?

> > In-memory metadata for remote relations will be created at query prepare time
> > when engine will able to extract query string and prepare it at remote data source
> >
> Too little too late. You have to solve the general metadata problem to
> be standard conforming.

Not sure it is too late, wait what Roman say.

> >> This may be more
> >> difficult than you expect since there can be name collisions between the
> >> remote and local RDB$RELATION_FIELDS.
> >>
> >
> > I hope we will avoid it ;)
> >
> How?

For now i not convinced problem even exists. I may be wrong of course.

Note that nor ORACLE nor MSSQL does not force users to store external
metadata in local database (as ASA does). And by my opinion this is strong
positive

> > I think not about "mega-database manager" but about more or less smart
> > client (or gateway) built in to the core engine and parser\optimizator\executor
> > extensions allowed to deal with this gateways.
> >
> There isn't any difference except that you are co-mingling the code into
> the engine rather than making it a component in its own right.

Where i did it ? Explain please

> If you think about it a bit more, I think you will realize the

> a) you can borrow the Vulcan encapsulated parser,

Why it better than our existing one ? I really don't know (i worked with, let say,
another Vulcan's parts), tell please

> b) the optimizer for network
> wide queries is radically different than the local table-only optimizer,

Am i said that optimizer will not be affected ?

> c) the common part of the execution engine is too trivial to worry
> about.

I tend to agree here

> > Perhaps i not understand yours meaning of "mega-database manager".
> > I've read about Ingress's one and found it ugly, hard to use and failed
> >
> >
> Now that's a brilliant argument! Could you elaborate? What did they
> do? Why was it hard to use? What didn't work? Was it slow? Got the
> wrong answer?

In two words : it force user to register everything in central distributed
database and it force user to work via this database every time he\she need
to query more that one database at time. This is enough to me (as applied
developer) to not like it very much.

This is my opinion (not an argument, if you wish) and i not going to
discuss it, sorry

> Have you investigated the MySQL federated storage engine? It does
> approximately what you are suggestion, though in a radically different
> architecture (MySQL, for example, doesn't have system tables).

No. I not investigated any aspect of MySQL. Surprise ? But i have
some expirience with MSSQL and wish we have the same level of
flexibility and usability it have. Does you investigated MSSQL's
Distributed Query Architecture ?

Vlad