> >> 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
> >
> Architecturally, it is a must have. Cursors are part of standard SQL,
> so support must not be precluded even if it isn't implemented in a first
> version.
>
> On the other hand, I don't see how you can avoid implementing them.

I mean not cursors at all but positioned updates.

> >> 8. Works with the existing BLR client interface (quibble nor or lose
> >> the right later!)
> >>
> >
> > Good to have but not necessary
> >
> I agree that it isn't necessary, but since SQL disappears early in the
> request compilation process, I don't see how you can both base the
> implementation of the existing engine and not support BLR.

Perhaps i not fully understand what you mean then. I want to say that
if some aspect will be supported via SQL but not via BLR (passed from
client) - we can live with it. However for now i can't imagine such aspect ;)

> >> 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"
> >
> "Transparent" means that an external database table is semantically
> identical to a local table and can be used without changing the client
> or tool.

Agree

> "Works with" means that the client or tool may have to be
> modified to know which tables are external database tables and which are
> real and to manipulate them differently.

Also agree : "client or tool may have to be modified"

> In my mind, "transparent" is the gold standard. Why should a client or
> interface layer have to care about where a table is or what hoops the
> greater database system must jump through to access it. To the client,
> a table is a table is table.

Agree

> >> 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.
> >
> I think you want to think about this some more. Is a DBA going to be
> really happy giving a single access account for all remote users,
> essentially delegating his responsibility to an engine outside of his
> administrative control. I think he would be a lot happier if he could
> set up a mapping of local to remote accounts so the final level of
> access control is performed at the remote system.

Hmm... I meant exactly that ;) And such mapping is present in my proposal,
see below

> >> 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
> >
> Duh. (Meaning, sure).

Can't disagree ;)

> >> 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
> >
> No, there has never been anything in DSRI, OSRI, Interbase, or Firebird
> that said that system tables can't be extended. We even went to great
> length to support user extensions to these tables. It is absolutely
> legitimate to add additional fields. That a nice thing about the
> relational model, you know....

Yes, but how existing (old) drivers will work with example above ?

> I think you will need at least:
>
> 1. A "create external database" statement or equivalent that
> specifies a name and an access string.

CREATE | ALTER EXTERNAL DATA SOURCE in my proposal

> 2. A system table RDB$DATABASES (or something)

"The list of external data sources is stored in local DB in the new system
table(s)" - also from my proposal

> 3. Some statements to define mappings between local accounts and
> external database accounts.

CREATE | ALTER EXTERNAL USER in my proposal

> 4. A system table or two to handle #3.

Also present

> Just in case, as the original OSRI architect and inventory of the
> original system tables, I hereby give you full permission to extend them
> (wisely!) to do anything that needs doing.

Ah, thanks ;)

> Just keep it transparent, please!

You'll look after it, i'm sure ;)

Regards,
Vlad