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

Bruce Momjian wrote:
>
> > > My initial reaction was the same as yours: put it in current sources,
> > > but don't backpatch. But with both Fernando and Neil vouching for the
> > > correctness of the patch, I'm willing to assume it's okay.
> >
> > I'll second that. (For me) the criteria for backpatching is that more
> > than one person is willing to *really* verify that the patch is Correct.
>
> OK, this is what I needed to hear. Patch applied to both trees.
>

Thank you!

> Let me reiterate my hesitation to apply this. First, 7.1.3 was supposed
> to be packaged up Tuesday night (two days ago), meaning I thought it was
> closed already. Second, I don't trust a patch to be 100% safe no matter
> who submits it. We had patches created and applied to 7.1 by core
> members that we thought were safe but in fact they were not and caused
> problems in 7.1.1 that were only fixed in 7.1.2, so "I don't trust no
> one." :-) Third, the evaluation of whether a patch is even safe takes
> time, and the farther we get from a major release, 7.1 in this case, the
> less likely we are to even take the time to evaluate it.
>

I believe we all agree with that. It just happened that this one was a
win-win situation. The options were: 1) totally broken (without the patch)
2) Probably fixed (with the patch). There was no chance of affecting
anything else that was not broken before due to the scope of the patch.

The customer who had the problem applied the patch and is now very happy
with his Python interface. Add this to Gerhards experience and ours,
to the limited scope of the change and the fact that was completely
broken before, and you see that it is a special case.

> Having a bug fix is not enough justification to get it backpatched.
> Most people want their patch backpatched, but if you look at the CVS
> HISTORY for 7.1.3 you will see that very few items are backpatched. We
> have over a dozen jdbc bugs fixed in CVS, but we aren't backpatching
> those because we are focused on 7.2, which is pretty close now. People
> who report JDBC problems are encouraged to use the CVS version or the
> one on http://jdbc.fastcrypt.com.
>
> I know it is not fun to ship bugs in 7.1.3 that we know we could fix,
> but with limited resources and testing, we are doing the best we can.
>

But JDBC for 7.1 was a lost case, while the one line change saves us from
having to adopt the same criteria for Python folks. I rather see they use
the version that is shipped from the pgsql tree and help fix it than using
the alternative ones that Gerhard mentioned. (For many, using the
development version is not an option).

> If someone would like to take the responsibility of backpatching more
> aggressively, we should discuss that.
>

I personally agree with the current rules. This was an exceptional case
where there was much to gain and little to lose. The only bad thing was
to give you extra work to repack things, for which I apologize.
But you can rest assured that it was worthy of your effort: Python seems to
have a growing number of adepts.

Best regards,
Fernando

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