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

But meaning of "catalog" is defined by database vendor. And we may or may
not treat external data sources as catalogues.

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

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

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)

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

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

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

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

I hope you'll change your minds ;)

Regards,
Vlad