> Does JDBC spec have a requirement to query _external_ catalogues ?
> Or it not divide catalogues by local\external ?
>
> It may be reason to not treat the name of external data source as catalogue

It does not distinguish between local and external tables. It speaks
about catalogs, schemas and tables/procedures/functions/etc.

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

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

>> The issue b) is more problematic, since the result set might refer to
>> the external table, but the SQLDA does not contain enough information
>> for the ResultSetMetaData interface. At the moment Jaybird queries
>> information from the system tables, but that is just a solution for the
>> current case.
>
> We may provide such information with long identifiers via existing isc_dsql_info call

That is not the best solution - you will have one more roundtrip, but
that would work.

>> The ResultSetMetaData interface must provide:
> ...
>> The ParameterMetaData has only one problem - the precision. This is
>> clear requirement for XSQLVAR extension.
>
> This also may be returned by isc_dsql_info using new tags.
> This will not require any changes nor in wire protocol nor in client API.
>
> 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.

Roman