Daniel Rail wrote:

>>At 07:36 AM 12/23/2004, Jim Starkey wrote:
>>
>>
>>>That's a different issue. What was proposed was an open ended INSERT
>>>... RETURNING <variable>...
>>>
>>>
>
>
>
>>What gets returned for a mass insert?
>>
>>
>
>It should generate an error.
>
>
>
>>Or is the RETURNING only
>>allowed for a singleton insert?
>>
>>
>
>For the usage to make sense, it should be only allowed in singleton
>inserts.
>

I agree, sort of. For that usage to make sense, it can only be allowed
in single inserts. That suggests to me that the mechanism is too weak
and restricted to handle the general case. Isn't it just as important
for a program doing a mass insert to find out what actually happened as
it it is for a single insert?

This is where I think we are:

1. It is useful and beneficial for a program performing an insert to
determine what actually got stored.
2. It is useful and beneficial for both singleton and mass inserts.
3. JDBC defines a getGeneratedKeys facility that is ill-defined and
probably unimplementable for an engine that support key
generation by user defined triggers
4. Oracle defines a SQL extention that return specific values that
apparently only works for singleton inserts. (Does anyone know
this for sure?)
5. The Firebird engine supports a general mechanism (blr_store2) for
fetching values "as inserted" and a general mechanism for
returning an arbitrary number of record structured messages.

Unless somebody else has a candidate mechanism to consider, it appears
that a unilateral, unscanctioned SQL extension is called for. Or we
could use the Oracle syntax and redefine it to mean a record stream, not
scalar values.

Or something else...

>
>
>