At 06:48 PM 9/16/2004, Helen Borrie wrote:

>How big of a leap would it be to implement these temp tables as a special
>class of external tables? I seem to recall, Ann, that you said there was
>already unfinished stuff in place to support structured external table
>files (dBase, CSV?)

Sorry, perhaps I'm being obtuse here, but external and temporary seem
orthogonal to me. There's nothing particularly temporary about ISAM
files or dBase. There's no reason why Firebird temporary tables would
behave differently from other Firebird tables.

>It would take all but the metadata stuff right outside of
>transactions. Indexing apart (which is likely to be a problem with temp
>tables, whatever you do), the write-once-read-many model seems to be there
>already and would offer more capabilities for the end use of the tables -
>applications that want "tables" for displays and database reports have
>them; and those that want external formats have them too.

Again, not so clear to me. Temporary tables are often write-many-times
as their contents are refined.

>Directory location decides who sees them - connection_id + transaction_id
>determines who owns them.

Directory location makes me queasy - I like being able to move databases
around and having the directory part of the semantics seems dangerous.
The model under current discussion is that the temporary table is known
only to its owner ... the question is how to identify the owner, given
that various tools pool connections, always connect through a single user,
and need tables that persist across transactions.

Regards,


Ann