Martijn Tonies wrote:

>Not having to run the clean-up procedure yourself is exactly
>one of the reasons why temp-tables are, well, not "needed",
>but surely very convinient.
>
>
>

I don't think it is a question of whether they are needed or not, but
whether how much they're needed, especially when compared to other
things on the plate.

Personally, I think the priorities for developers should lean towards
cleanup of the internal infrastructure before we add more external
features. Things that I see are more important than temporary tables are:

1. Purification of syntax tree nodes
2. Replacement of yacc/bison with a hard code recursive descent parser
3. Recast of RSB as a type hierarchy
4. Recast of expression EXE nodes as a type hierarchy
5. Recast of boolean EXE nodes as a type hierarchy
6. Recase of statement EXE nodes as a type hierarchy

I'm a feature kinda guy. Performance is sine qua non and standard
conformance is a cost of doing business, but clever functionality that
addresses real problems was what makes databases fun. All that said, in
the short term, getting our house in order now will grease the skids for
adding new features later. Just imagine how much more fun it will be
when adding a new SQL features is no jore than a couple of lines in the
parser, a couple of lines in pass1, a new subclass an execution type
hierarchy, and a line or two in the optimizer?