Nando Dessena wrote:

>
> would it be that much of an overhaul to allow passing TDSs as
> procedure parameters and map the local declaration to an inbound
> parameter name? Example:
>
> create procedure fattest_cats (counter integer,
> fatter_cats transient data set)
> returns (name varchar (30), age integer, salary integer)
> as
> describe fatter_cats
> (name varchar (30), age integer, salary integer);
> begin
> ...
> end

Err, I've missed something... What do you gain by passing the
transient data set to the procedure rather than just allowing a
reference - like a reference to a table? You don't pass tables to
procedures... Possibly that would allow a program to create a transient
data set with one name and pass it to a procedure that calls it
something else. Is that important if the structure of the two has to be
identical.

> I can see it's ugly, but I fear that a more elegant solution would
> involve stricter typing through domains and require the use of domains
> as procedure parameters:
>
> create domain d_fattest_cats
> as table (name varchar (30), age integer, salary integer);

And that gets wholly away from the point of transient data sets -
defined on the fly - and completely in the range of the Global Temporary
Tables that Vlad proposed, where the metadata is permanent and stable.
Useful things, but useful in a different context. Maybe the right
answer answer is that procedures and transient data sets don't mix and
if you want to use private data with procedures, use global temporary
tables.

> A> Is it important to be able to destroy a transient data set?
>
> if it's global, yes. If not, scoping rules would do.
>

I'm not sure... Scoping makes lots of sense in hierarchies - applying
it in a flat names space doesn't seem all that clear. I can certainly
understand a procedure creating a transient data set and having it go
away when the procedure exits. However, that idea leads to massive
monolithic procedures, which are, IMHO, a bad thing.

Regards,


Ann