Subject | Re: [Firebird-Architect] for discussion Transient Data Set |
---|---|
Author | Jim Starkey |
Post date | 2005-01-15T12:28:22Z |
Dmitry Yemanov wrote:
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.
>"Ann W. Harrison" <aharrison@...> wrote:Why wouldn't it? Is there a problem you know of?
>
>
>>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 librariesWould we consider both? RETURNING requires a whole new API. YIELDING
>>that want to provide a list of values from a singleton modification.
>>
>>
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 isHmmm...
>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.
>
>
>