> >> But if objects in external database are not accessable via catalogs on
> >> the JDBC level, no tool will see them. That will cause problems for O/R
> >> mappers, for example, that query system information on initialization.
> >
> > Hmm. It is hard to imagine application which connects to one database
> > to store objects in another ;)
>
> Well, this argument can be used to question the need of external tables
> at all - any client application can connect to two databases and query
> them independently with post-processing on the client side (QLI).
>
> The Java O/R mappers are quite sophisticated, it is far beyond simple
> object per table mapping. And they allow quite sophisticated OQL queries
> which can affect many tables/schemas.

And many different servers through the one connection ? Ok, it is far
from perfect from performance POV, but if you said they realy do it i can
only agree with you...

You see - i can change my minds :)

> > Anyway. If driver queried system tables defined by standard (information
> > schema is standardized, AFAIK) and database implements it - then i see no
> > problem. The problem is to support standard's information schema.
> >
> > (My humble opinion is that this issue have a lowest priority)
>
> Sorry, I do not understand you here - what has lowest priority:
> supporting standard information schema (are we talking about SQL
> standard, btw?) or providing access to external tables through JDBC?

Support standard's monstrous information schema

Regards,
Vlad