Re: Could postgres be much cleaner if a future release skipped backward compatibility?

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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate