On Wed, 2003-10-01 at 11:48, Joshua D. Drake wrote:
> Sure but businesses don't like to upgrade unless they have too.
Granted, but maintaining old releases doesn't come at zero cost. It may
benefit some users, but the relevant question is whether that benefit is
worth the cost. The time someone spends backpatching changes into old
releases (and thoroughly testing those changes, and fixing the
regressions those changes cause) is presumably time that would otherwise
be spent improving the latest release of PostgreSQL.
So when the bugfix is important, has been well-tested, and is unlikely
to cause regressions, backpatching the change to previous stable
releases is a good idea. When this isn't the case (and even more so if
it's a feature and not a bugfix), I don't think it justifies the cost
(and the risk of destabilization) for most users.
In summary, I think the status quo is basically okay. Perhaps we should
backpatch a few more things, but we're basically in the right ballpark.
> In reality in place upgrade will never work.
Perhaps not, but the upgrade story can certainly be made more palatable.
I think that's the actual problem here -- rather than skating around it
by making it less necessary to do the upgrade in the first place, I
think our time is better spent making upgrades as painless as possible.
Just IMHO, of course (especially since I'm not particularly interested
in doing the work on the upgrade process myself).
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
