Subject RE: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables.
Author Ann W. Harrison
At 05:20 PM 11/23/2004, Samofatov, Nickolay wrote:

>Hi, Arno!
> > Can we rely on the ATTACHMENT_ID after a server crash. Isn't
> > there a chance the same (or lower) one is choosen?
>Attachment ID is generated from header page the same way as transaction
>Modified header page doesn't stay in cache for too long, it should get
>written to disk before any data page is written for attachment due to
>transaction cleanup reasons.

Ah. Nickolay just called and explained what I had missed. The idea
is that a temporary table has one more column than its definition
includes. That column contains the attachment id of the transaction
that stored the record. Attachment ids are handed out like transaction
ids, through the header page, but without the record-keeping that
transactions require.

The temporary table also has a special system created index on
the attachment id. If it has a primary key or unique index, the
attachment id becomes a segment of that key.