On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
> - If there is nothing that can be done in 8.3 at least warning should be > added into the documentation. It will be just one more don't in our long > list don'ts for our developers.
I am in favour of that change in the 8.3 branch.
> > ERROR: cache lookup failed for function. > - Could the plan be marked as invalid so it would fail only once so the next > call to the function would get replanned and work again. At least it would > be better than losing parts of application for indeterminate time.
That seems to me to be a behaviour change, not a bug fix. I agree that the current behaviour is pretty annoying. That is not the same thing as "a bug" except in the loosest sense. The system works as specified, and therefore it's not a bug. If the specification is wrong, you need a new specification; that's a "bug fix" that is usually pronounced "major release".
> - Could some less dangerous looking mechanism be added to 8.3 that wouldn't > make users not used to PostgreSQL limitations gasp for air when they see the > workarounds :)
I think it a very bad idea even to suggest that we start undertaking things like adding mechanisms to minor releases, even with smileys at the end of the sentence. I appreciate (possibly more than many hackers) the limitations that are imposed on users by some of the decisions historically taken by developers in some of the previous major releases. But I very strongly agree with Dimitri: the super-conservative approach to maintenance releases that this project takes is a really big benefit to users, and is ultra important in "mission critical" environments. Otherwise, it becomes practically impossible to get minor releases into production. If you have to worry about the possibility of major changes between minor versions, you will have to treat every release as a major release.
I don't think we have sufficient commercial integration support yet that we can follow the lead of the Linux kernel, where the system vendor has the effective obligation to make sure your kernel actually works.
In addition, if someone wants to develop back-patches for 8.3 that give it new functionality otherwise planned for 8.4, I see nothing wrong with them doing so. That's the advantage offered by having the source. But the idea that the new functionality should be patched back by the project because one is impatient is not on.
