Re: Patch: plan invalidation vs stored procedures

Every thread we are concerned in turns into something strange thing that is
almost entirely differnet from the original intention. First thread we
started was with the intention to discuss how we should handle the problem.
Instead of discussion it was trolled into oblivion. Then we thought so what
if no discussion we will submit a patch maybe people will understand we are
serious. Nothing relevant came up. Spent week more to refine patch into
something that looks good enough. And now we are having discusion what is
bug and what s not in this thread.

In the first message Martin asked
"There are probably a lot of details that I have overlooked. I'd be really
thankful for some constructive comments and criticism. Especially, what
needs
to be done to have this in the core. Feedback appreciated."

Can we get back to the topic?

PS: We have 10000+ functions (including lots of duplicates)
PS: We are able to be as arrogant as any of you but we can get more things
done with constructive comments.

On Wed, Aug 20, 2008 at 2:53 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
>
> 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
>