Thanks for a nice replay Andrew. So best solution for 8.3 is update pg_proc set proname = proname; whenever you need to drop and create functions or some in house patch.
Lets get on with 8.4 Asko On Wed, Aug 20, 2008 at 4:16 PM, Andrew Sullivan <[EMAIL PROTECTED]>wrote: > 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. > > A > > -- > Andrew Sullivan > [EMAIL PROTECTED] > +1 503 667 4564 x104 > http://www.commandprompt.com/ > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
