Re: executemany rowcount

On Sun, Feb 08, 2009 at 07:59:32PM +0100, Markus Demleitner wrote:

> > Yep, one might want to invoke a few stored procedures and
> > eventually get the net result of them with an explicit
> > SELECT.
> ...which doesn't work as expected in current bzr trunk due to my
> patch (OTOH, it didn't work as expected before either, since you'd
> have gotten a "no results to fetch").
> 
> In Karsten's scenario, you'd want to fetch as many rows as the last
> operation yielded.
Sounds entirely logical to me.

> So, the least intrusive way to implement this
> behaviour is to have another field in the cursor struct, maybe
> "last_rowcount", and have fetchXXX use that to figure out how many
> rows to retrieve.  For this I could gladly come up with a patch.
Or, perhaps, have a .accumulated_rowcount. As for myself, I
wouldn't know what logic would make the accumulation the
default rowcount returned by a multiselect.

> Finally, you could of course document that on multi-SELECTs, you will
> receive all-NULL rows for all statements but the last one.
> 
> That's ugly, but maybe tolerable to people actually using such
> constructs ("If you are devious enough to run into this situation,
> you are kindly asked to cope or to provide a patch").
Absolutely.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346