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.

Regards,


Ann