> Ann et al,
>
> Regarding temporary datasets vs PSQL.
>
> First, I think that everything DECLAREd within a procedure body should
> behave similarly. It means that either local temporary table or transient
> data set must be created at the declaration and destroyed upon procedure's
> exit. And also be visible only on a per-procedure basis. Exactly like
> DECLAREd variables and cursors behave. We don't need different semantics for
> the same syntax.

Agreed

> Second, I don't support a proposal to map existing DLTT/transient dataset to
> its local declaration. I believe it tends to cause structure mismatches that
> will bite everyone at runtime. Eevery structural change will require a lot
> of PSQL to be corrected as well. Too complex and risky to be used without
> worries.

Agreed

> Third, I think it's too early to talk about passing temporary datasets to
> the nested calls, either implicitly via scope inheritance or explicitly via
> formal parameters. Personally, I don't like a concept of nested visibility
> of local objects (declared at upper levels), be it a special declaration
> flag or implemented elsehow. If we want something to be used in the nested
> calls, just pass it via the stack (read: using formal parameters). This
> works for variables now. We should decide whether it's desirable for cursors
> and how it could be done (a tricky question). Then we should think how
> temporary datasets fit this semantics.

Need to think more on it

> Since my personal opinion is that PSQL-scoped datasets is a valuable thing
> to have, I see two possible solutions:
>
> 1) temporary dataset can be created/declared in PSQL, but it's still an
> independent session-scope object which is not destroyed upon procedure's
> exit. It's visible in nested calls, but this is okay as it's not a local
> object, it's just initialized in a procedure.

Don't like it

> 2) temporary dataset is declared in PSQL and have a procedure-scope
> visibility and lifecycle. It can be optionally initialized with a select
> expression and/or can be later changed, but its structure must be fixed for
> the given procedure. It can be passed to nested calls as an actual parameter
> value (realistically thinking, this feature is a separate one). Local
> temporary dataset name overrides every session-level table-type object, be
> it persistent table, GTT or another session-level temporary dataset.

This is the way to go, imho

I think that Ann's TDS (or something like it) is good for replacement of
standard LTT. But it bad fit into PSQL therefore PSQL needs another
entity. Of course implementation of all of the kinds of temporary tables
can (and will) have many common code. I think there is sense to
discuss it all in common


Regards,
Vlad