> The system result sets are what drive basically all database tools. If
> the goal is to to make external tables appear transparent to the client,
> there is no reasonable alternative to properly managing the system
> result sets.

The system result sets that you are talking about are virtual in case of
Jaybird. That means that we query the database for all needed bits and
bytes, and then construct an object that implements the ResultSet
interface and gives the needed data to the client. Sometimes we simply
copy data from the result set, but sometimes we have to generate data.

> I'm sorry if this is inconvenient, but there are reasons that external
> tables haven't been implemented over the 22 years since gds/Galaxy
> version 1.
>
> I'm not saying that it isn't a good idea or can't be done, but a proper
> implementation is quite a bit of work and I'm afraid there are no shortcuts.

Are you talking about the proper system tables in the Firebird that
would show the external tables?

>> If we implement catalogs (e.g. external data source is a catalog) and
>> engine provides a possibility to access the needed information in the
>> remote database via system tables or selectable system procedures (in
>> other words the parser would somehow distinguish the query involving
>> catalog name), that would work. For sure, we (driver developers) will
>> have to update drivers to support it, but that's ok.
>>
> If you say so, I guess, but that sounds to me like hand waving to avoid
> solving the problem.

Here I was talking about the technical possibility to implement it this
way. I don't like it, I'd prefer normal system tables, but I can hide
all details behind the ResultSet interface implementation.

Roman