executemany ('SELECT ...') (was: [DB-SIG] DBAPI-2.0 clarifications)

[M.-A. Lemburg]

"Dittmar, Daniel" wrote:
> 
> Whether executemany ('SELECT ...', [...]) returns one or multiple result
> sets, couldn't that be implementation dependant? Unless the client really
> wants to know which result record come from which input parameter record, it
> shouldn't really matter.
> 
> Why is this a problem?
> 
> When the database doesn't support array execution, implementing the notion
> of a single result set is at least cumbersome.
> 
> When the database does support array execution, then returning multiple
> result sets is inefficient (because multiple SELECTs have to be executed +
> possibly the overhead of closing the result sets). In addition, it would
> require different handling for INSERTs/UPDATEs and SELECTs, which (depending
> on the underlying API) might require parsing the SQL.
> 
> The client would have to expect multiple result sets.

I don't see your problem... if the DB does not support multiple
result sets, then .nextset() can simply be left unimplemented or
be implemented to always raise an exception (see the DB API).

Note that the original idea behind .nextset() was to allow
stored procedures to pass back multiple result sets. The idea
of having .executemany() produce mutliple result sets only came
up recently on the db-sig list -- I can't really say, that I like
it...

Snice it is not defined in the DB API spec, the feature is deemed
to be implementation specific. Multiple selects in one execution
block don't really make any sense if executed from within Python,
since passing in query parameters is not preformance relevant and
it only makes debugging code harder... IMHO, at least.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/