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

MSSQL have four-level namespace : server.database.owner.object
User may query all databases known at this server instance : master, tempdb, etc.
If he omit database name then MSSQL will use default one which is assigned or
at attachment level or at server level in login's properties.

It means that if we defined external data source connected to MSSQL then we
can query only one database at this server via this data source.

Not sure this is issue needs to be solved... just for info ;)

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

Hmm. May be we will add some magic here : if query to the system table
contains no reference to "catalog" field then this is old application, expected
to see local objects only ? In this case we'll embedd boolean ("catalog" = "local")
into the query

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

If query referenced "catalog" field then it queries whole system table.

Or we may add some new DPB tag to define scope of metadata visibility ?

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

All applicatin may query all accessible tables without any additional efforts.
Only system tables content are under question

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

Please, no ;)

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

No, what is it ? :)

Vlad