> > 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.
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.
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.
If someone would like to take the responsibility of backpatching more
aggressively, we should discuss that.
--
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