Re: Could postgres be much cleaner if a future release skipped backward compatibility? - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Date
Msg-id 87oco26t81.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Could postgres be much cleaner if a future release skipped backward compatibility?  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> I'm sure the casting changes broke more applications and prevented more
> people from upgrading than every thing on Ron's list for a clean 9.0 would.
> Not that I'm necessarily promoting his idea, but 8.3 was already a
> "all-at-once breakage" release.

I'm having to support 8.2 because that's the most recent upgrade we can
afford on some project here, for this very problem. I don't think
removing support for add_missing_from would stop us from upgrading to
8.5 (or call it 9.0) from 8.3+. Or more to the point, that the cost to
migrate from pre-8.3 to any 8.[345] releases would change much.

As far as breaking historical compatibility where it matters for a next
release, I think it boils down to older releases mainteance. The way I
see it, if 8.5 or 9.0 breaks a lot of warts but 8.0 (or 8.1) to 8.4 are
still maintained the way they are now, this will be just an usual
PostgreSQL major upgrade headache (and revenue source for contractants).

It seems such a little game changer that I won't care voting for or
against it. Please continue considering code maintenance as a higher
priority target than upgrade easyness, that seems to open the road for
more stability and features in the long run.

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Next
From: Tom Lane
Date:
Subject: Re: Controlling changes in plpgsql variable resolution