Re: Fix for fetchone() and fetchmany() in Python interface

Bruce Momjian wrote:
>
> > Bruce,
> >
> > It may be too late for including it, but it would not be for the reasons above.
> >
> > 1) low risk
> >
> > It is low risk. It is a one line patch that only affects the python interface code.
> >
> > 2) major
> >
> > It is major. Without it we can consider that 7.1 does not support Python
> > (at least, not the 2.0 API).
> >
> > What use is an interface that keeps returning the same row (the first one)
> > every time you call the cursor trying to get the next row?
> >
> > It happens with both functions fetchone() and fetchmany(), so there is no
> > workaround besides reading the whole table (which sometimes is not feasible).
> >
> >
> > So, it is both low risk and major.
>
> If it has taken months for someone report report it and fix it, it can't
> be that major.
>

Maybe people are using the old interface pg.py and that one is not broken?
Or people tried to use the new interface (pgdb.py) and gave up because it
didn't work (and went on to use some other DBMS)?

It took us a couple weeks to get the first customer complaint, which is a
very short time. We sent them Gerhard's patch and they are quite happy now
(thanks Gerhard!).

Regardless of the conflicting bug report statistics, just think how you would
use a binding that fails on the following (hint: fetchmany() does not work either).

row = c.fetchone()
count = 0
while row != None:
print count, str(row)
count = count + 1
row = c.fetchone()

You can only do:

count = 0
for row in c.fetchall():
print count, str(row)
count = count + 1

which will not work if your table is big.

So, with 7.1.2 you can only use the old interface or forget about Python
(or use Gerhard's patch).

--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9