> - 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@commandprompt.com
+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
No comments:
Post a Comment