Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Fernando Nasser <fnasser(at)cygnus(dot)com>
Cc: lockhart(at)fourpalms(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, gerhard(at)bigfoot(dot)de, pgsql-patches(at)postgresql(dot)org
Subject: Re: Fix for fetchone() and fetchmany() in Python interface
Date: 2001-08-16 16:08:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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
> > 
> > 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).


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

In response to


pgsql-patches by date

Next:From: Bruce MomjianDate: 2001-08-16 16:09:23
Subject: Re: Fix for fetchone() and fetchmany() in Python interface
Previous:From: Fernando NasserDate: 2001-08-16 15:58:54
Subject: Re: Fix for fetchone() and fetchmany() in Python interface

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group