Subject Re: Counter proposal to Temporary tables
Author paulruizendaal

You have pretty much summed up how I wanted to do temporary tables
for Fyracle. As Fyracle largely sits between the client and the
engine, it can create the extra columns, views, etc. on the fly; it
can intercept attach/detach, commit/rollback and do some of the
cleanup automagically.

I guess this means too that it is conceivable to do a workable
implementation of temp tables by upgrading only the DSQL module. It
might be hard on the tool people, though.


--- In, "Ann W. Harrison"
<aharrison@i...> wrote:
> 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