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

Federico Di Gregorio fog@mixadlive.com
Tue, 20 Mar 2001 15:57:29 +0100


Scavenging the mail folder uncovered Dittmar, Daniel's letter:
> > can you explain what an "array select" is
> > and why choosing (a) would "hide" it on sap and oracle?  

[example snipped]

> This is of course more efficient than sending three SELECTs and fetching and
> closing three result sets.

agreed.

> If the DB API standard would require to produce a separate result set for
> each input parameter set, then there would be no way to specify the
> behaviour described above, thus 'hiding' this feature.

i understand. so the problem is that *some* db can be made more efficient
by choosing a certain solution while the others, missing UNION, will
emulate it. given that a db missing UNION still has to do some bookeeping
and and serialize the queries, i am beginning to think that returning a
single set that is the sum of all the queries is the right thing. also,
i can't see a case where returning different sets will help the application
writer (he will use a for to cycle on the sets anyway, so he can just put 
the *select* inside the for.)

is this a kind of resolution on executemany()? what do the others think?

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
                           Don't dream it. Be it. -- Dr. Frank'n'further