> > 1. Registration of an external source of the data
> >
> > CREATE | ALTER EXTERNAL DATA SOURCE
> > <ds_name>
> > PROVIDER <provider_name>
> > CONNECT <ds_connection_string>
> > [AS {USER <external_user> [PASSWORD <external_password>] | CURRENT_USER}]
> > [OPTIONS < ds_options >]
>
> I have asked whether we're talking about the Firebird DBs only or
> external data sources in general.
>
> If later - I'm not ok with [AS {USER ... | CURRENT_USER}] mechanism
> since it is very limited.

It may be and will be implemented at least for databases served by the same engine.

> Here we have to consider all plans that Alex
> has for PAM-based authentication. In general it has to pass some list of
> credentials (user/password pair, certificate, etc.).
>
> If former - we don't need PROVIDER clause then - it should be part of
> Firebird. BTW, we don't have clause to register provider :)

Because we don't need it. If provider will be regular Vulcan-style provider
it will be registered in appropriate config file

> > 2. Login mappings management
>
> User name/password is not enough, we have to support certificates at
> least. I think we should split security part into another thread.

While i agree that we may discuss security separate i not agree we _must_
support anything except password. If we will support certificates - good. But, please,
not require it

> > 4. Heterogeneous queries to external data source
> >
> > Table qualifier: <ds_table_name>@<ds_name>
>
> I'd suggest to extend the tables like this:
>
> CREATE TABLE table [EXTERNAL {[FILE] 'filespec' | DATA SOURCE <ds_name>}]
>
> CREATE VIEW name [(view_col [, view_col .])]
> {AS <select> [WITH CHECK OPTION] | DATA SOURCE <ds_name>}
>
> That means that external tables has to be defined in the database
> explicitly. As to the explicit queries - if they are used often - people
> can define them as views (finally - as selectable procedures, add syntax
> extension to CREATE PROCEDURE statement).

This way is used by ASA. I very very not like it. It is hard in use and require many
efforts from end-user.

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

I not agree with you here. As for me cross-database queries must be as easy from
end-user POV as usual queries

> > It is necessary to think up a way to set an external table name with its full qualification by
> > external engine rules. it is possible to quote full name but it is easy may not fit in ours 32
> > symbols and it is not clear how to quote external quoted identifiers;)
> >
> > 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.

This is the only positive i see in extending CREATE TABLE :)

Regards,
Vlad