Dmitry Yemanov wrote:

>"Ann W. Harrison" <aharrison@...> wrote:
>
>
>>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.
>>
>>
>
>Perhaps. My main worry is whether a YIELDING result can be considered
>expected/correct after a multiple rows DML statement or not.
>

Why wouldn't it? Is there a problem you know of?

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

Would we consider both? RETURNING requires a whole new API. YIELDING
does everything RETURNING does plus a lot more, and can be implemented
with a standard SQL API. There is absolutely no way, for example, to
graft RETURNING onto ODBC or JDBC. YIELDING is just a language
extension with no effect on API. Yes, our new API could have provision
for RETURNING, but only programming that cut over to it could access the
functionality.

>They're always based on a partial/simplified query expression which is
>implicitly defined. So I don't think this is a problem. But I would like to
>avoid including YIELDING into a select expression. Recently I've extended
>the parser to make all subselects true select expressions. Generally, now
>the only difference between nod_select and nod_select_expr is FOR UPDATE and
>WITH LOCK clauses. I'm sure we don't need YIELDING in subqueries.
>
>
>

Hmmm...