Dmitry Yemanov wrote:

>
>
> Let's get back to the original talks about RETURNING. It's required >for two things: (a) return underlying table data after a DML operation

That I agree. When a record has a system-generated primary key, there's
no reliable way to get back to it after an insert. A RETURNING clause
would reduce the cost/complexity of storing a tree of related objects.
The solution we currently offer - call gen_id first to get the key, then
do the store - is awkward and a barrier to people moving applications or
even skill sets from other databases to Firebird.

>and (b) do it in a single network roundtrip with a base DML.
>The latter requirement is very important.

I'm not sure that it's very important, but I understand that it would be
desirable.

But it seems it cannot be done for multiple row updates. So, we have two
options:

>
> 1) Forget about returning datasets from multiple row updates (my proposal)
> 2) Forget about single network roundtrip (your proposal)
>
> Probably, we could implement both, but it would require two different
>extentions (e.g. both RETURNING and YIELDING) for the affected DML, which
>looks like a mess.

YIELDING works with singleton and mass modification verbs (insert/
update/ delete), but requires a second round trip. Returning works only
with singleton modifications, but works in a singe round trip. I'd
argue that both are valuable in different contexts.

>
> Another issue is namespaces. How should a connectivity library generate a

tds name for a particular INSERT to ensure this name becomes unique and
won't
generate an exception?

I think that RETURNING is probably better for connectivity libraries
that want to provide a list of values from a singleton modification.

You raise good points. If YIELDING is part of a query expression, then
a statement like this solves the problem of getting values from a mass
insert...

INSERT INTO <whatever> SELECT <list> FROM <data source> YIELDING ...

A question is whether the ability to return a transient data set from an
update or delete has value, since those operations are not based on a
full query expression.

Regards,


Ann