Re: executemany rowcount

On Sat, Feb 07, 2009 at 08:26:32PM +0100, Markus Demleitner wrote:
> Hi,
> 
> On Sat, Feb 07, 2009 at 06:39:57PM +0100, Federico Di Gregorio wrote:
> > Il giorno ven, 06/02/2009 alle 12.00 +0100, Markus Demleitner ha
> > scritto:
> > > Hi,
> > > 
> > > At some point between 2.0.6 and 2.0.8 the old executemany/rowcount
> > > behaviour of just leaving the rowcount of the last execute alone got
> > > fixed to have executemany always leave a rowcount of -1.
> [...]
> > >    We want meaningful rowcounts for an executemany.  The rules are:
> > >    The rowcount is the sum of all individual rowcounts, except when
> > >    a single rowcount is -1.  In that case, and when an error occurs,
> > >    the whole rowcount is -1.
> > 
> > Seems fine and it also passes the DBAPI tests. I integrated your patch
> > and it is now in bzr. Many thanks.
> Except when I was cycling home, I seemed to remember that rowcount
> was also used in fetchXXX.  And sure enough, the program
> 
> import psycopg2
> 
> conn = psycopg2.connect("dbname=test")
> curs = conn.cursor()
> curs.execute("CREATE TEMP TABLE foo (x INTEGER)")
> curs.executemany("INSERT INTO foo VALUES (%(x)s)", (
> 	{"x": i} for i in range(20)))
> curs.executemany("SELECT * FROM foo WHERE x=%(x)s",
> 	[{"x":1}, {"x":2}])
> print curs.fetchall()
> print curs.rowcount
> 
> (assuming you have a database test) goes bad.  Its output is:
> 
> [(2,), (None,)]
> 2
> 
> Now, I'm happy that psycopg didn't segfault, but this certainly is
> not desirable behaviour.

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.

SO, probably the best thing is to document this behaviour and let
it as is

federico