Subject Re: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables.
Author Adam Clarke
Hi Paul,

Some questions, corrections

Paul Beach wrote:
> Syntax:
>
> CREATE TEMPORARY TABLE <table name> <table contents source>
> [ON COMMIT {PRESERVE | DELETE} ROWS]

> Semantics:
> An entry for relation <table name> is made in the RDB$RELATIONS system table. Entries are made in RDB$RELATION_FIELDS and
> RDB$FIELDS relations describing the fields listed in the <table contents source>, as they would be for a permanent table. The
> entries in RDB$RELATIONS, RDB$FIELDS, and RDB$RELATION_FIELDS are provisional and unusable until the transaction which issued the
> CREATE statement commits.

Will an attempt to create a temporary table with the same name as an
existing temporary table (from another uncommitted transaction) fail
even it you use ON COMMIT DELETE? I would hope not because this
simplifies the use of temporary tables, otherwise you must manage
conflicts yourself somehow.

> All connections can see the definition of temporary tables; temporary tables are part of the global name space. No connection can
> see data stored in a temporary table by another connection.

Once committed with "ON COMMIT PRESERVE" only, or in both cases?

> A temporary table can be either the referenced or referencing table in a foreign key constraint, but the partner table must
> be a temporary table. If either table is ON DELETE COMMIT, both must be ON DELETE COMMIT.
>

I think the above should read "ON COMMIT DELETE" x 2.

Cheers

--
Adam Clarke
Strategic Data Pty Ltd
www.strategicdata.com.au
Adam.Clarke@...
[p] +61-3-9348-2013
[f] +61-3-9348-2015