> >> This is less of a performance hit, but
> >> still has a version skew problem. Whatever the scheme, however, you
> >> have to solve the problem somehow or break most tools and the ODBC and
> >> JDBC drivers.
> >
> > May i ask our ODBC\JDBC developers if it is required to return information
> > from external schemas ? Roman ?
>
> There are two issues in JDBC:
>
> a) general metadata information available in the DatabaseMetaData
> interface. Those are information about schema, tables, columns,
> procedures, etc.
>
> b) result set metadata available for each result set at runtime.
>
> In general I see no problem with a), since we're not supposed to provide
> all schema information for an external database, even people can queue
> it. Or better to say, the only possibility to make it work in JDBC is to
> treat external database as catalog. In this case we have to be prepared
> to handle "dotted" SQL queries like
> "some_catalog.some_schema.some_table". That also means that we have to
> support schemas (at least some default name).

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

> 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

> 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

> I cannot tell a lot about ODBC, but I suspect that the requirements are
> similar.

Me too

> >>> In-memory metadata for remote relations will be created at query prepare time
> >>> when engine will able to extract query string and prepare it at remote data source
> >>>
> >> Too little too late. You have to solve the general metadata problem to
> >> be standard conforming.
> >
> > Not sure it is too late, wait what Roman say.
>
> If we implement catalogs (e.g. external data source is a catalog) and
> engine provides a possibility to access the needed information in the
> remote database via system tables or selectable system procedures (in
> other words the parser would somehow distinguish the query involving
> catalog name), that would work. For sure, we (driver developers) will
> have to update drivers to support it, but that's ok.
>
> Same applies to the result set meta data - we need such information only
> after preparing the query.

Very well and as i expected.

Thanks,
Vlad