> Vlad Horsun wrote:
> >> Would the engine understand the @ syntax and ignore anything metadata related
> >> coming from that?
> >>
> >
> > Engine will understand @ syntax and will check remote query fields against field
> > names specified in query and data types of target variables\parameters.
> >
> > It is described at (6.a) section (referred as "EXECUTE STATEMENT ... ON" but
> > applicable to any remote query)
> >
> >
>
> How do you propose to handle metadata and system tables? Existing tools
> are going to expect that RDB$RELATIONS, RDB$FIELDS, and
> RDB$RELATION_FIELDS are appropriately populated?

At my understanding, existing tools expect correctly filled SQLDA after
isc_dsql_prepare call. I see no reason for tool makers to expect stored
metadata describing external objects.

In-memory metadata for remote relations will be created at query prepare time
when engine will able to extract query string and prepare it at remote data source

> This may be more
> difficult than you expect since there can be name collisions between the
> remote and local RDB$RELATION_FIELDS.

I hope we will avoid it ;)

> The last dozen or two times this has come up, the architecture has been
> to make a provider (the "mega-database manager") that handles cross
> database stuff rather than trying to integrate the mega-database manager
> into the existing Firebird database engine. Starting over with a clean
> implementation designed to support the specific problem at hand would
> probably be easier and better than trying to get a 23 year old database
> engine to handle something it was never intended to do.

I think not about "mega-database manager" but about more or less smart
client (or gateway) built in to the core engine and parser\optimizator\executor
extensions allowed to deal with this gateways.

Perhaps i not understand yours meaning of "mega-database manager".
I've read about Ingress's one and found it ugly, hard to use and failed

Regards,
Vlad