Dmitry Yemanov wrote:

>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.
>
>

Is your objection with the syntax or the concept? The concept that a
procedure may need to reference something that doesn't exist at compile
time but will at runtime is pretty solid. We can pick a word other than
"declare", but personally I don't think there is enough confusion
between declaring a variable whose scope is the procedure and declare
what is in essence is a forward declaration using the same keyword.

>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.
>
>

What are the problems? The declaration doesn't even have to match the
actual definition. We have always supported access to records created
by earlier generations of the metadata without trouble. Transient
dataset declarations are the same logical and physical problem that can
be dealt with the same rules and mechanisms.

>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.
>
>

I don't think that passing transient data sets or, for that matter,
ordinary tables as parameters is an obviously good idea. There is no
question that it would be hard to implement and harder to implement
efficiently. But I also don't see the benefit over traditon naming
mechanism.

>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.
>
>

Scoping a transient dataset is unnecessary and weakens the power of the
idea. Being able to invoke one procedure to create a transient data set
and another to process it is a very powerful way to structure a system.
Going out of our way to make this impossible makes no sense to me.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376