>> 2. Preserve standard SQL semantics for statements that reference more
>> than one database.
>
> SQL standard is not clear about such statements. There are terms "catalog"
> and "schema" but there are no clear statement that "catalog" may be remote
> database or outside of local\current database. Correct me if i'm wrong

Well, I think standard does not reject the possibility that catalog can
be remote database. The "catalog", "schema" and "table" build a
three-level namespace. From my POV the mapping "external data source" ==
"catalog" is correct now and will be correct when we introduce schema
support.

>> 11. Works with the existing ODBC drivers.
>> 12. Works with the existing JDBC drivers.
>> 13. Transparent to clients.
>> 14. Transparent to ODBC drivers.
>> 15. Transparent to JDBC drivers.
>> 16. Transparent to tools that use native Firebird system tables.
>
> It depends on what you mean by "works" and "transparent"

I would say that the requirements are:

11a) existing ODBC/JDBC/etc. drivers can work with the "mega-database"
without any changes, but we do not require them to "see" the remote tables;

11b) new ODBC/JDBC/etc. drivers get the means to query information about
the external databases, [schemas], tables, etc. This can be an extension
of the existing system tables/views or new API.

Alternatively we can require

11c) existing ODBC/JDBC/etc. drivers must be able to work without any
changes also with the remote tables as if they were local tables;

11d) users might be required to perform some necessary tasks to satisfy
11c).

>> This a starting point. Other folks may want to add or remove from these.
>
> 20. Not force users to put much effort to maintain this new facility

Possible conflict with 11d) :)

> Why ? To introduce external entities in local database we need to at
> least add some fields into existing RDB$xxx tables. This means that existing
> drivers and applications can't correctly query new RDB$xxx and must be
> upgraded : imagine two tables T in two different catalogs : X.T and Y.T
> (or T@X and T@Y) - existing drivers not know about catalogs and will think
> database have two tables T.
>
> To preserve compatibility we must not extend RDB$xxx and put
> external entities into some new tables

Well, you can always rename the table locally, e.g. T@X is T_X and T@Y
is T_Y. Remember CREATE TABLE <local_name> EXTERNAL <ds_name>? :)

Roman