Re: Fix for fetchone() and fetchmany() in Python interface - Mailing list pgsql-patches

> > 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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026