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

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

Nice you could test the patch in a live situation. We don't normally
get that.

> > 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

Agreed, a lost cause. It was frozen in February, 2001.

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

Yep.

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

Seems it has not been packaged yet, or at least I haven't heard about
it, so we should be OK.

Sounds good. As long as you don't mind the extra effort you had to make
to sell the patch, I think we have a good system.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026