Re: Patch: plan invalidation vs stored procedures

<div dir="ltr">Every thread we are concerned in turns into something strange thing that is almost entirely differnet
fromthe original intention. First thread we started was with the intention to discuss how we should handle the problem.
Insteadof discussion it was trolled into oblivion. Then we thought so what if no discussion we will submit a patch
maybepeople will understand we are serious. Nothing relevant came up. Spent week more to refine patch into something
thatlooks good enough. And now we are having discusion what is bug and what s not in this thread. <br /><br />In the
firstmessage Martin asked <br />"There are probably a lot of details that I have overlooked. I'd be really<br />
thankfulfor some constructive comments and criticism. Especially, what needs<br /> to be done to have this in the core.
 Feedbackappreciated."<br /><br />Can we get back to the topic?<br /><br />PS: We have 10000+ functions (including lots
ofduplicates)<br />PS: We are able to be as arrogant as any of you but we can get more things done with constructive
comments.<br /><br /><br /><div class="gmail_quote">On Wed, Aug 20, 2008 at 2:53 AM, Andrew Dunstan <span
dir="ltr"><<ahref="mailto:andrew@dunslane.net">andrew@dunslane.net</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;"><divclass="Ih2E3d"><br /><br /> Tom Lane wrote:<br /><blockquote class="gmail_quote" style="border-left: 1px
solidrgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Also, there are a whole lot more
considerationsin a backpatch decision<br /> than just "is it a bug".  The (estimated) risk of creating new bugs and<br
/>the extent to which the patch will change behavior that apps might be<br /> relying on are two big reasons why we
mightchoose not to back-patch<br /> a bug fix.<br /><br /><br />  <br /></blockquote><br /></div> Right. And even if it
isa bug the question might be "what sort of bug is it?" We might well be prepared to take some risks with code
stabilityto plug security or data corruption bugs, a lot more than we would for other sorts of bugs. Even if this were
considereda bug instead of a limitation, it doesn't come into the class of things we should be rushing to fix in the
stablebranches, unless the fix is fairly obvious and of limited impact, which is clearly not the case.<br /><br />
cheers<br/><font color="#888888"><br /> andrew<br /></font></blockquote></div><br /></div>