>> 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 :)

I did not say that we must handle external tables via JDBC the same way
as we treat internal ones.

I said that more or less intelligent Java code relies on
DatabaseMetaData interface to provide information about every accessible
thing in the database. And, _if_ we want to provide developers a
possibility to use external tables using O/R mappers or other tools,
_then_ the external tables must be visible via DatabaseMetaData. And on
that level we have "catalog", "schema" and "table" concepts.

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

Since I did not check the SQL standard on this regard, I can't comment.
But my guess would be that our system tables are not standard compliant
anyway (and Oracle's as well), so for the moment we can go our path.

Roman