Re: Fix for fetchone() and fetchmany() in Python interface
От | Bruce Momjian |
---|---|
Тема | Re: Fix for fetchone() and fetchmany() in Python interface |
Дата | |
Msg-id | 200108161608.f7GG8Ho27970@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Fix for fetchone() and fetchmany() in Python interface (Fernando Nasser <fnasser@cygnus.com>) |
Список | 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
В списке pgsql-patches по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: Fix for fetchone() and fetchmany() in Python interface