> > PROVIDER <provider_name>: string - identifier of plugin realizing work with an external
> > data source. Most likely - a name of dll, by analogy with UDF
> >
> Not agree on this.
>
> Should be better to use a logical provider name, mapped to a physical
> file through configuration, as fbintl.conf do.

This was my intent ;) Perhaps badly formulated

> > 4. Heterogeneous queries to external data source
> >
> > Table qualifier: <ds_table_name>@<ds_name>
> >
> @ is special symbol in ADO.NET meaning parameter, but I don't expect
> problem here, as Oracle uses same syntax.

Ok

> > It is necessary to teach parser and optimizer to cut from heterogeneous query such parts
> > which may be sent to an external engine. Also it is necessary to demand ours SQL syntax and to
> > decide where to handle built-in functions and aggregates. Not clear how to handle joins of local
> > and external tables - to put the external table at outmost place (and fetch all rows, but only
> > once) or to put it at inner place (and to execute set of parametrized queries on external data
> > source for every row fetched from local table)
> >
> Will the FB provider be a totally external provider?

Yes

> Can't it be made in a way that cross queries between FB databases in
> same engine are handled most like single DB queries?

I doubt it possible without serious work on engine internals. If we make exportable all
info needed to our optimizer we'll reach near the same performance level, i think

> > Separate question - EXECUTE STATEMENT not in PSQL block. In this case formats message's for
> > client can be defined only when the text of query is known, i.e. during call isc_dsql_prepare the
> > text of query should be known (may not be a parameter).
> >
> > For those who wants prepared reusable EXECUTE STATEMENT with parametrized text of query - will
> > wrap it up in PSQL, for example in EXECUTE BLOCK.
> > However for now EXECUTE STATEMENT may not be used outside of PSQL block ;)
> Why one would need EXECUTE STATEMENT outside PSQL block, instead of just
> prepare the SQL directly?

Because EXECUTE STATEMENT ... ON will pass query string directly to remote SQL engine.
It will not make attempt to parse and understand potentially unknown syntax.

This is very close to Pavel's proposal about special kind of stored procedure (if i understand
him right) for this purpose.

Regards,
Vlad