Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>The concept that a
>>procedure may need to reference something that doesn't exist at compile
>>time but will at runtime is pretty solid.
>>
>>
>
>Perhaps. It's the same as EXECUTE STATEMENT. And if we go this way, very
>strong type and structure checks must be enforced.
>
>

I don't think so. EXECUTE STATEMENT necessarily uses just-in-time
compilation. If it references a non-existent transient data set it will
fail during compilation, which is ok, because it's going to fail anyway.

>
>
>>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.
>>
>>
>
>I'm sure we need true local temporary datasets. It should use the DECLARE
>syntax then, to be consistent with other locally declared object types. In
>this case a forward reference should be declared differently.
>
>

There we talking syntax, not semantic? Right?

>
>
>>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.
>>
>>
>
>I strongly disagree. Everything used without a compile check must be checked
>as strongly as possible at runtime. I don't want to see metadata formats
>applied to transient datasets.
>
>

That's the way the system work now. Everyone I know of thinks that the
ability to retain table contents over metadata revisions is feature, not
a bug. If one part of an application systems changes the details of a
transient data set, how is this any different?

>
>
>>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.
>>
>>
>
>It allows temporary datasets which are created and used locally only. No
>need for application to know anything about them.
>
>

I don't understand how this fits into the SQL language or our
implementation. Could you elaborate on how you can passed objects
referenced?

>
>
>>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.
>>
>>
>
>Being able to use whatever temporary data locally to a single PSQL call
>makes a lot of sense. If we don't want monster monolitic procedures, a local
>dataset must be passed to inner calls, if required. Although I agree that
>your usage pattern is also possible.
>
>

My usage requires session level scoping. It can't be done any other way.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376