Andrew Dunstan <[EMAIL PROTECTED]> writes:
> 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.
As indeed we have done, and lost the bet more than once :-(. Rev 8.2.2
and siblings being the most recent example. A quick review of the
release history will show other cases where well-intentioned, seemingly
safe back-patches broke things.
Now security patches are the worst-case scenario for this, because they
typically go out with no significant public review. But even a regular
bug-fix patch doesn't get all that much testing in the back branches
before it hits the streets as a supposedly-stable update. By and large,
if we commit something into REL8_3_STABLE today, it's going to appear
in 8.3.4 with nothing more than buildfarm testing. That is a sobering
prospect, and not one that makes me want to put nontrivial patches in
there except at great need.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
