Dmitry Yemanov wrote:

>
> First question, whether it defines a query or a data set?

Materialized data.

>
> If this is an actual data set, then how does it differ from LTTs?

1) Local temporary tables are defined in the SQL standard to have the
scope of SQL modules. We don't (yet) implement SQL modules so local
temporary tables are irrelevant and inapplicable to Firebird.

>
> So we have a result assigned to some "table variable" which can be
> referenced later? Sounds like a real data set.

It is a real data set that is automatically destroyed at the end of the
SQL session that created it, unless it is explicitly dropped earlier.

>
>>A transient data set is destroyed when the session ends or with the drop
>>transient data set statement: DROP TRANSIENT DATA SET <name>
>
> Equal to DROP TABLE for a LTT.

Or DROP TABLE for a real table. Or DROP TEMPORARY TABLE for a global
temporary table.

>

>
> The major question then. Where are the data (both rows and index b-tree)
>
> stored? Are blobs supported? And again, what is the actual difference
> between your proposal and already discussed LTTs (considering the
> suggested CREATE AS SELECT extention)?

The semantics are very much like the semantics _we_ wanted for local
temporary tables. The name space is restricted to the SQL session, the
data goes away when the session exits. Unfortunately, the standard
defines different semantics for local temporary tables, specifically
that they are restricted to a SQL module. Grafting non-standard
semantics on standard language is bad design and restricts our ability
to implement the standard in the future.

The advantages of the proposed syntax over the syntax of the standard
include 1) The declaration and modification of transient data sets are
DML, so we don't get into the DML/DDL mire. 2) for the same reason,
transient data sets can be used in procedures. 3) a tds can be used to
redefine itself - through projection, union, join etc.


Regards,


Ann