From: "Roman Rokytskyy"

> My comments:
>
> > 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. 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 :)
>
> > 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.
>
> > 3. Direct (pass-through) queries to external data source (not

heterogeneous)

>
> Not sure I like it... see below.
>
> >
> >
> > 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).
>
> 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.

Why not? This is how "Linked Servers" work in MS SQL Server.

If Firebird can do this without having to define the tables "locally", I
think
it's better.

Of course, things would get complex if you actually tried using non-local
tables in Stored Procedures with regard to binding of columns and run-time
errors.

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com