> It should be handled at the RSE level instead.

Agree.

I looked at this about 18 months ago and I thought that the most likely
route to get this done would be to extend the external table code.
Instead of performing file ops, the code would issue SQL commands to
another FB instance or an ODBC driver.

Simplistic code is not all that hard to do (but not so easy that I got
it done back then). The difficulty is in optimization. Rather than
retrieving a long record set and filtering that, clever code should
push as much of the processing to the remote source to minimize the
amount of data in transit. This means that the FB optimizer should take
into account if part of a WHERE clause can be factored out, and
included into the remote SQL request.

Taking optimization further, it could try to figure out if makes sense
to push sorting operations to the remote source as well. A very clever
approach would take into account which indexes exist on the remote
source and use that info in deciding an access plan.

This product seems semi-clever about it all (but I have never tried it
myself):
http://www.easysoft.com/products/data_access/odbc_odbc_join_engine/index
.html

> And this feature is already scheduled for implementation.

Great. I would already be very happy with a simple implementation.

Paul