Ann,

No-one used COALESCE before it existed.

No-one used UDFs before they existed.

No-one used Stored Procedures before they existed.

They all could be "worked around". How is this an argument
against functionality that with which we could "tick of" another
"SQL standard" item?

How is this an argument against easier transaction from other
engines?

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.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com

> Given that we've largely agreed
>
> 1) that temporary tables must be created in a separate
> transaction and committed before use, and
>
> 2) that the definitions of temporary tables are visible
> to all attachments, and
>
> 3) that the <as subquery> clause is a separate issue
> with some significant complications, and
>
> 4) that a reasonable implementation of temporary tables
> is to add a (magic, invisible) field to the table
> that identifies records as belonging to a connection
>
> why do we need temporary tables at all? Why not use
> a conventional table with fields defined to contain
> the connection identifier and the current date? Those
> two fields can be filled in with triggers. Create a
> view that excludes the connection and date and filters
> on the connection, and you've got a temporary table,
> lacking only cleanup. Use a simple procedure that
> filters on the date field from time to time to remove
> data more than two weeks old.
>
> Not perfect, certainly, but free, and doesn't involve
> mucking with internals at all.