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

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

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

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

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


Dmitry