Re: Patch: plan invalidation vs stored procedures
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joshua Drake <jd@commandprompt.com>
Cc: Bruce Momjian <bruce@momjian.us>, Gregory Stark <stark@enterprisedb.com>, Hannu Krosing <hannu@2ndQuadrant.com>, Asko Oja <ascoja@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Dimitri Fontaine <dfontaine@hi-media.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, David Fetter <david@fetter.org>, Martin Pihlak <martin.pihlak@gmail.com>
Date: 2008-08-19T23:32:25Z
Lists: pgsql-hackers
Joshua Drake <jd@commandprompt.com> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm not sure that I *want* a formal written-down backpatch policy. > Then we write a formal guideline. It really isn't fair to new developers > to not have any idea how they are going to be able to get a patch > applied to older branches. Something like: > Generally speaking we adhere to the following guideline for patches. > * Security fixes are applied to all applicable branches. > * Bugfixes are applied to all applicable branches > * Note: A patch that addresses a known limitation is generally > not backpatched > * New features are always applied to -HEAD only. 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. 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. regards, tom lane