> Volker to appear here with his comments...

What Volker really wanted was:

I have been following the discussion in fb-architect. I think Ann's counter
proposal is only straightforward, since the original proposal (global temp
tables) had almost nothing to do with what I had asked for and is really only a
marginal improvement over the current situation probably not worth the
considerable effort.

What I had asked for is much closer to derived tables than to global temp
tables. Derived tables make it possible to work with several different *result
sets, not tables* at the same time on the server. Metadata of the participating
subqueries is defined only by the query and therefore as dynamic as can be. The
drawback with derived tables is that it all has to happen within one query if
result sets need to be related. I cannot put a part of such a query result
somewhere (on the server, that's the important thing here) and continue to work
with it. Using derived tables for my purposes (making Firebird act as an OLAP
engine) I might find myself squeezing 5, 10, 20 or so subqueries into one huge
megaquery. That's why I asked for local, session-specific temp tables, to be
able to first collect result sets on the server which have no fixed metadata and
then continue to work with them on the server.


Regards
Paul