Local temporary tables [CORE720]

[firebird-automations]

Submitted by: @pcisar

Votes: 32

SFID: 807942#⁠
Submitted By: pcisar

Allow for the definition of temporary tables which are only visible within the current connection context and which are deleted upon connection disconnect/lost.

[firebird-automations]

Commented by: Alice F. Bird (firebirds)

Date: 2004-05-24 12:53
Sender: agjedrus
Logged In: YES
user_id=749589

great feature really usefull but with implementation like is done in MSSQL

[firebird-automations]

Commented by: Dejan Schild (schild)

It's really time to implement this feature, it's very needed for reporting,...

[firebird-automations]

Commented by: Maxim (paratruper)

Pleas see key core -961. May be is better to choose not context connections, and a context of transaction?

[firebird-automations]

Commented by: @hvlad

Maxim, how 'Free external tables' is related to the 'Temporary tables' ?
It seems you mixed two different things

[firebird-automations]

Commented by: Mirco Malaguti (mirmalag)

Would be useful to declare the lifetime of the table, either the connection or the transaction in which the temporary table is created, e.g.:
CREATE TEMPORARY TABLE FOO (
...
) DROP ON COMMIT/ROLLBACK | DISCONNECT;

Mirco

[firebird-automations]

Modified by: @dyemanov

summary: Temporary tables => Local temporary tables

[firebird-automations]

Modified by: @pcisar

Workflow: jira [ 10744 ] => Firebird [ 15129 ]

[firebird-automations]

Commented by: Umberto Masotti (umasotti)

Maybe I've missed something, but if Fb 2.1 GTT solve completely this feature request, maybe it's time to close it.

[firebird-automations]

Commented by: @dyemanov

Global and local temporary tables are two different things. This ticket refers to the latter one.

[firebird-automations]

Commented by: Cosmin Apreutesei (cosmin_ap2)

I second Mirco's idea -- otherwise procedures won't be re-entrant in the same connection and there's no easy way to make them so (you'd have to implement DROP IF EXISTS).

[firebird-automations]

Commented by: Cosmin Apreutesei (cosmin_ap2)

On a second thought, this won't be enough for all cases (you can still call the same procedure in the same transaction twice and the CREATE will fail), so the best way is for them to apply the same lifetime rules as for local variables.

Or better yet, let us declare variables in the procedure body and apply full lexical scoping. It's just a feature request so any amount of fantasizing is allowed right?

[firebird-automations]

Commented by: @dyemanov

I don't think you need to apply your fantasy. The SQL committee had already decided everything we would implement.

[firebird-automations]

Commented by: Cosmin Apreutesei (cosmin_ap2)

> The SQL committee had already decided everything we would implement.

No good deed ever goes unpunished.

[firebird-automations]

Modified by: Sean Leyne (seanleyne)

description: SFID: 807942#⁠
Submitted By: pcisar

Allow for the definition of temporary tables which are
only visible within the current connection context and
which are deleted upon connection disconnect/lost.

=>

SFID: 807942#⁠
Submitted By: pcisar

Allow for the definition of temporary tables which are only visible within the current connection context and which are deleted upon connection disconnect/lost.

[firebird-automations]

Commented by: robert gilland (robert.gilland)

I have just moved company after working with firebird since 2003, and being a major contributor to it.
My new company uses "SQL anywhere".
I cannot even begin to recommend Firebird to my new company unless this is implemented
An example of this is below:

ie. inside a stored procedure

declare local temporary table Foo(
FooCode char(10) null,
) on commit preserve rows;