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

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

Agreed.

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

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.


Dmitry