> May I suggest that we temporarily place Vlad's proposal on hold and go
> back to where we should have started, which is with the requirements.

No problem

> Good design really must start from a clear statement of the
> requirements. Without an common understanding of the requirements, how
> can we all know what we're trying to design, or whether a particular
> design is insufficient or complete?
>
> This isn't my design (I'm actually on vacation on my boat), but I'll
> start the ball rolling. Pardon me if I state some of requirement as
> questions.
>
> I think the requirements for external database access are:
>
> 1. The ability to give a single SQL query that references tables in
> more than one database.

Yes

> 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

> 3. Preserve standard SQL cursors, including "current of cursor".

Good to have but depends on support from remote side. Not sure it is
high priority feature

> 4. Preserve transaction ACID properties in transactions that
> reference more than one database.

Must have

> 5. Preserve proper access control and security across various target
> databases.

Must have

> 6. Permit reasonable optimization of cross databases and cross
> network queries.

Good to have but any optimizer may be improved continuously

> 7. Provide transparency between various local and remote databases.

Yes

> 8. Works with the existing BLR client interface (quibble nor or lose
> the right later!)

Good to have but not necessary

> 9. Works with the existing SQL client interface.

> 10. Works with the existing remote interface, server, and line protocols.

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

> 17. Tolerant of metadata skew when a remote database is altered
> without notice.

Yes

> 18. Should all users of a external database table use the same account
> and password?

No, because it conflicts with :

> 19. Should access control to external database tables be defined at
> the database level or (redundantly) at the external database table
> level?

At external level only.

> 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

> There is always a trade-off between transparency and ease of
> implementation. Where does it make sense to break transparency to
> simplify impementation? For example, from before the birth of
> Interbase, the table RDB$RELATIONS provides a list of tables within a
> database and a join of RDB$RELATION_FIELDS and RDB$FIELDS generates the
> list of fields within a table.

> For transparency, external database
> tables should be described in these system tables as ordinary tables,
> external file system tables, and views.

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

Vlad