On Tue, Oct 20, 2009 at 10:46:10AM -0400, Andrew Dunstan wrote: > Robert Haas wrote: >> I think the real issue, though, is that answer to Ron's original >> question is "No". When backward compatibility gets in the way of >> cool new features, that's worth considering. But removing backward >> compatibility just for the sake of removing backward compatibility >> doesn't really buy us anything. It's basically doing extra work >> for no benefit and some possible harm. > > Well said. > > I am singularly unimpressed by arguments for removing backwards > compatibility features to satisfy someone's passion for neatness, or > to force people to conform to how they think their software should > be managed. I occasionally shake my head in amazement at the > willingness of some people to throw other users under the bus.
This isn't about a "passion for neatness." It's about recognizing that some experiments have failed and weeding out the failures. The RULE system, for example, was a ground-breaking innovation in the sense of being a truly new idea. Evidence over the decades since has shown that it was a *bad* idea, and I like to think we're going with an evidence-based approach. Things like add_missing_from and regex_flavor, to name two examples, are just bletcherous hacks invented to solve no-longer-extant problems. The burden of keeping things like this in the code base is large and increasing. There's even a name for it: technical debt. http://en.wikipedia.org/wiki/Technical_debt If we're to remain a successful project, the vast majority of our community is that of future users, not present or past, so worshipping backward compatibility is rejecting the needs of the many in favor of the few. Let's at least think a bit before we make a decision to do such a thing. > Upgrading a database installation is hard enough without us > gratuitously making it harder, and we positively don't want to make > people stay on older releases if they don't have to, I should have > thought. Upgrading a database installation should be made easier in a lot of different ways, not least that a postmaster should be able to point to an older database instance, possibly with some kind of prep procedure, and do the right thing. What we have now (Slony, pg_upgrade) is a bit better than, "fire up pg_dump and take the down time," but it needs a lot more love. This is for the benefit of our entire community, not just the present one. :) Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers