At 10:21 AM 12/4/2004, Paulo Gaspar wrote:

> >>Adding a non-standard temporary table
> >>implementation will make future standards a choice between
> >>doing the right thing - maintaining backward compatibility
> >>and doing the right thing - following the standard.
>
>Actually, there are a lot of ways to work around such limitations when
>you already know the standard.

I'm not at all sure you're right about that, but beyond that, my
concern was with future directions of the standards committee, a
subject on which I would not dare to speculate. If we bend the
standard a bit now in one direction to meet our needs, we run
the risk that they will take the new standard off in a different
direction, making our changes grossly non-standard and impossible
to reconcile with the standard.


A problem with the temporary table discussion is that we realized,
at least I did, fairly well into the topic, that we were actually
trying to deal with several different problems under the same name.

1) creating and maintaining connection private data that
can be queried and updated like data in the database.

2) creating tables (permanent or temporary) that look like
nd may contain the data from query result sets.

3) establishing a private name space.

In the process we ran into one perfectly legitimate difference
between Firebird and other standard-compliant database, to wit,
Firebird DDL statements are transaction-based and schema objects
can not be used, even by their creator, until the transaction
that created them has committed.

There are lots of people on this list who would like to change
that last behavior. And perhaps we should. But we shouldn't
change it piecemeal as part of a temporary table implementation.

Regards,


Ann