Vlad Horsun escreveu:

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

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

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

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

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


Adriano