Re: executemany rowcount

On Sun, Feb 08, 2009 at 07:10:58PM +0100, Karsten Hilbert wrote:
> On Sun, Feb 08, 2009 at 12:39:35PM +0100, Federico Di Gregorio wrote:
> 
> > As you say below, executemany() is supposed to NOT be used with multiple
> > SELECT statements. There was a discussion a couple of years ago about
> > checking the query and raising an error on SELECT but we decided to
> > let the client code decide what is good for it. I don't see many uses
> > if SELECT in executemany() but I also don't see why issuing multiple
> > selects should raise an exception if you know what you're doing.
> 
> 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.  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.

I still feel that using postgres' idea of how many rows a FETCH will
yield directly in fetchXXX would be preferable, but I'm a bit daunted
by having to take apart the prefetch logic, so I'd be more reluctant
here.

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

Cheers,

         Markus