> We may have PROVIDER as not required clause - missing provider means
> connection to local server.

Ok.

>> I do not consider the cross-database queries as something that should be
>> very flexible - at the end it is about integrating two databases, not
>> about acting as router to another DB.
>
> Please take a look at QLI syntax - it supports cross-database queries for a
> long-long time. Why should we invite bycycles here?

Yes, but that thing is on the client. No problem with that. The issue
with seamless integration of distributed databases is that we convert a
server into some kind of advanced BDE with all arising limitations. That
is why I have asked whether we do generic external data sources or
Firebird-only ones. We can greatly optimize solution for local-Firebird
case (SS at least, not sure about CS), but we will have problems in
generic case. And I'd like to see integration capabilities with other
RDBMS engines as well.

>>> Here i see 2 possible strategies of work :
>>>
>>> ?) Distinguish each external table, to request its format,
>>> cardinality, indexes and their selectivity and to remember this
>>> information similarly to ours jrd_rel. It will do DSQL in pass1. GEN will
>>> build usual rse with blr_remote_relation instead of blr_relation. Further
>>> work with these remote_rel as with usual tables - build rsb for each of
>>> them, etc. CMP will build parametrized queries for external data sources
>>> from these rsb's
>>>
>>> Pluses: relative simplicity, possibility to not touch optimizer.
>> I'd go for this approach in the first place, probably I would provide an
>> option to CREATE TABLE clause that would refresh
>> statistics/cardinality/indexes from remote data source periodically.
>
> Is it very hard to get this data from remote database?

I guess all database engine have some means to query this info, so it
should be possible, even if it means provider per server scenario.

>>> Also such names will not fit in SQLDA. The truth, it not problems for
>>> work with external FB data source.
>> If we extend the CREATE TABLE declaration as shown above, this problem
>> disappears - it will use local identifiers.
>
> Newer version of SQLDA? Or even move to newer API, like isc_dbc?

Yes. Newer version of SQLDA or new API. That is not that hard from
technical POV, but I see it as a problem when we consider how many
component suits we have to update...

Roman