> > Why not store them in the database file itself?
>
> Two reasons. Clean-up and performance. The performance reason is

that

> the temporary file could be a RAM file, which the database can't. The
> clean up of a temporary file is instant and automatic.
>
> > As I see it, it would simplify the implementation since the engine

would

> > see the TDS just like a real table (registered in RDB$RELATIONS),

and

> > all existing table functionality would be supported.
>
> After the first reference, the engine gets all its information from

the

> Relation objects and their various relatives. The system tables are a
> bootstrap mechanism. The earlier discussion of temporary tables
> provides a general architecture for mapping a relation to a different
> file.

Doesn't this in-memory structure and the earlier implementation
discussions mean that FB would never be able to work in
clustered/fail-over environments?

By creating additional files wouldn't this further increase the
co-ordination required between the cluster nodes?

Whereas, by adding the data to the existing db file would mean that the
TDS would fall under the standard db 'coordination' activities.

Shouldn't those environments be considered when discussing/considering
new features? (They are a growing presence in IT shops)


Sean