>> That means that any Java tool is able to display all schemas in the
>> catalog, and all tables/procedures/functions/etc in a schema. Like any
>> other standard it does not speak about the implementation details
>> (whether that is system table query or API call, whether table is local
>> or remote).
>
> It is ok. But - from where this Java tool know catalog name ? Another
> information call returned all known catalogues ?

Yes - DatabaseMetaData.getCatalogs() call returns a result set with one
column with catalog name. We can query the registered data sources here.

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

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

>> And if they are accessible via catalogs, then other automated tools will
>> use <catalog>.<schema>.<table> syntax in the generated SQL (for example
>> that was an issue with Eclipse). And I have no desire to convert it into
>> <table>@<datasource> syntax in the driver - we don't need SQL parsers in
>> the driver.
>
> Till now nobody requires you to do it ;)

Huh?

> No. There are no needs in additional roundtrips. Engine returns information
> pieces which was requested by client. You just add some more isc_dsql_info_xxx
> into information request passed in op_prepare_statement packet and parse answer
> on client side. As Jaybird have its own protocol implementation it not depends
> on XSQLDA\XSQLVAR formats. I.e. this change may be implemented even today not
> breaking anything

Ok.

>>> More - if JDBC\ODBC will use isc_dsql_info to query catalogue then we may
>>> delegate this work to the provider(gateway) serving external data source
>> Yes, this is a solution, though I do not like it (nothing concrete, only
>> that I don't like it). We have to define the list of tags, but that
>> should work.
>
> I hope you'll change your minds ;)

Well, I'm not going to veto only because I don't like it (even if I had
a veto right, anyway :)).

Roman