Le mercredi 20 août 2008, Tom Lane a écrit : > That just begs the question of what's the difference between a "bug" and > a "limitation". AFAICS, having such a policy/guideline/whatchacallit > in place wouldn't have done a single thing to stop the current flamewar, > because the people who want this thing back-patched are insisting that > it's a bug, while those who don't are saying it's a long-known > limitation.
As a person who previously insisted it was a bug, I'd like to take the opportunity to claim that I didn't realize this was a limitation of the design of plan invalidation, which now seems related to DDL operations. Realizing this earlier would have resulted in no mail at all on this thread from here. There's certainly a balance between -hackers readers not doing their homework and people in the know choosing not to re-estate known things... > Also, there are a whole lot more considerations in a backpatch decision > than just "is it a bug". The (estimated) risk of creating new bugs and > the extent to which the patch will change behavior that apps might be > relying on are two big reasons why we might choose not to back-patch > a bug fix. And this way the project works is what leads its users not to fear minor upgrades, which is something I (we all?) highly value. Regards, -- dim
signature.asc
Description: This is a digitally signed message part.
