>>> 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>}]
> Your variant means that names of tables in both database will be identical. It is not always comprehensible. Vlad's variant can be solve next use case:
> select ... from Table1@DS1 join Table1@DS2 on ...

Well... you'll have to create TABLE1_DS1 and TABLE1_DS2... Now you ask
what if I add one more table and later another table... and so on.

I am not against Vlad's solution in general. The issue that I have, is
the API change required to incorporate the long table names. Maybe that
is very clean approach to add such dependency and wait until we solve
this issue, but on the other hand the external procedures that Vlad, you
and myself created, were presented in 2005, in 2006 they were pretty
stable, now we have end of 2007 and they won't be included in server
before end of 2008... somehow that is not ok, even I was the first at
the last year conference who said after Dmitry's presentation that FB
3.0 must be very simple merge of FB 2.1 and Vulcan and we can't allow
external procedures there.

The CREATE TABLE extension works with old API, I guess it can make it
into FB 3.x (together with external procedures, probably PAM
authentication), which, if everything goes fine will be somewhere end of
2008. If we start designing new API that would be rather FB 4.0 (I, for
example, want schemas there, another thing for the API change)... And
that is somewhere end of 2009-2010... And the CREATE TABLE extension
does not prevent table@ds syntax to be introduced in FB 4.0 and both
will be able to co-exist (simply add a preprocessor that will convert
the external table name into table@ds name and pass to the parser).

> Also change of a name of the table in external database will demand a re-registration of this table. It is more movements, probability of an error hence there is more.

It's a matter of taste, I think. Change of the name in another database
requires a change in our database (e.g. in PSQL code) and/or change in
the application code. So whether you use ALTER TABLE syntax or you do
ALTER PROCEDURE, it does not really matter.

Roman