> Adriano, in technical discussion it is more often persuasive to reason
> than conclusions. I know you are convinced you are right, but that is
> not the issue. You must convince *us* that you are right.

The same about you, Jim. And about me and all others. Let's play
by common rules.

...

> > This "gateway" could also be inside the engine.
> >
> Indeed it could. But putting it inside the engine raises more problems
> that it solves.

"Ah, a divine revelation? A statement of faith? An epiphany?" (c)

> For example, there is the system table / object name
> problem. And the optimizer problem. The question, however, is not
> whether it could be done, but whether it is better to do it than the
> known alternatives.

You give no reasons (except of "statement of faith" (c)) why it is better
to separate "gateway"

> Vlad's proposal did not address any of these issues.

It not adressed only unknown (at that time) for me problem with ODBC\JDBC
drivers. All other at least described. And i didn't said my proposal is complete
and ready to be implemented as is.

> Perhaps we should
> allow him the time to ponder the issues and come up with suitable solutions.

Yes

> > It's much more user friendly to just declare a "db-link" and use it than
> > create another database, in a provider that will be almost untested (too
> > much people lived without cross db queries and will continue living).
> >
> > Think about a production environment, accessing just one external table
> > when necessity arrives...
> >
> I don't think that there is any disagreement that Vlad's proposal could
> be hacked in to handle "just one external table". But could it be
> extended to muliple tables?

It not needed to be "extended to multiple tables" it already described this

> Tables with conflicting object names?

Where you see this issue with my proposal ?

> Could it reasonable optimize network queries?

Yes

> Could it support the tools already in place?

It will

> > For example, Oracle engine doesn't support the command DESC (our ISQL
> > SHOW TABLE, for who doesn't know), but I can "desc x@z" in SQL*Plus and
> > it shows the metadata.
> >
> Do you consider that good enough?

Yes, this is good enough. At least for start

> Are you prepared to write off existing tools?
> > I don't thing we need to store or retrieve external metadata from our
> > system tables.
> >
> >
> >
>
> Please explain why. Are you arguing that ODBC and JDBC are not
> important? Or just stating an opinion based on, well, nothing?

Why ODBC\JDBC support require from us to _store external metadata_
into _our_ system tables ???

One solution i can imagine is to introduce additional tables (REM$RELATIONS, etc),
populate it on demand and create views with union of this tables and existing
system tables. Drivers will query this views to retrieve necessary metadata info.
This tables might be virtual, temporary (but visible by all attachments) or even
persistent (not sure its a good idea as data in this tables are volatile)

Anyway, if drivers must query our system tables then our system tables must
be extended to support at least catalog's and schema's and, perhaps, long identifiers

Regards,
Vlad