| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Joshua Drake <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Asko Oja <ascoja(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, David Fetter <david(at)fetter(dot)org>, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> |
| Subject: | Re: Patch: plan invalidation vs stored procedures |
| Date: | 2008-08-19 23:53:02 |
| Message-ID: | 48AB5CDE.5060802@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> 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.
>
>
>
Right. And even if it is a bug the question might be "what sort of bug
is it?" We might well be prepared to take some risks with code stability
to plug security or data corruption bugs, a lot more than we would for
other sorts of bugs. Even if this were considered a bug instead of a
limitation, it doesn't come into the class of things we should be
rushing to fix in the stable branches, unless the fix is fairly obvious
and of limited impact, which is clearly not the case.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2008-08-20 00:35:02 | Re: Patch: plan invalidation vs stored procedures |
| Previous Message | Tom Lane | 2008-08-19 23:45:16 | Re: Patch: plan invalidation vs stored procedures |