On Tue, Oct 20, 2009 at 11:48 AM, David Fetter <da...@fetter.org> wrote: > 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.
I don't think that's true. That's just an assertion on your part, and I don't think there's any evidence to back it up. > 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. I think we usually think pretty carefully about these decisions on a case-by-case basis. Making a blanket policy, as proposed here, would NOT be thinking carefully. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
