Ann,

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

A> Err, I've missed something... What do you gain by passing the
A> transient data set to the procedure rather than just allowing a
A> reference - like a reference to a table? You don't pass tables to
A> procedures...

well you don't create tables in procedures either. You wrote:

A> I tend to write small procedures that perform specific transformations,
A> so I need the ability to create a transient data set in one procedure -
A> or in my code - and transform it in another procedure. Allowing a
A> procedure to use a previously constructed transient data set is very
A> attractive.

Parameters seemed like the most straightforward solution to that to
me. Of course everything you can do with a parameter you can do with a
global as well. When "table" becomes a data type, then the physical
tables are just global variables and it makes sense to allow table-type
references as parameters. But I can see for myself I'm rambling quite
away from the problem at hand.

>> create domain d_fattest_cats
>> as table (name varchar (30), age integer, salary integer);

A> And that gets wholly away from the point of transient data sets -
A> defined on the fly - and completely in the range of the Global Temporary
A> Tables that Vlad proposed, where the metadata is permanent and stable.

Yes. I've gone astray.

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

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

Plus, if the procedure passes the dataset to another procedure you
have to manage pass by reference and possibly reference count the
datasets so you know when to destroy them. An explicit destroy
operation looks more viable.

Ciao
--
Nando Dessena
http://www.flamerobin.org