Re: Patch: plan invalidation vs stored procedures

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 <ajs(at)commandprompt(dot)com>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
> ajs(at)commandprompt(dot)com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>