Re: Patch: plan invalidation vs stored procedures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: plan invalidation vs stored procedures
Date
Msg-id 14700.1219188745@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: plan invalidation vs stored procedures  (Joshua Drake <jd@commandprompt.com>)
Responses Re: Patch: plan invalidation vs stored procedures  (Andrew Dunstan <andrew@dunslane.net>)
Re: Patch: plan invalidation vs stored procedures  (Dimitri Fontaine <dfontaine@hi-media.com>)
List 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


pgsql-hackers by date:

Previous
From: daveg
Date:
Subject: Re: A smaller default postgresql.conf
Next
From: Tom Lane
Date:
Subject: Re: Patch: plan invalidation vs stored procedures