From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | "Greg Sabino Mullane" <greg(at)turnstep(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Could postgres be much cleaner if a future release skipped backward compatibility? |
Date: | 2009-10-20 14:22:06 |
Message-ID: | 87oco26t81.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Greg Sabino Mullane" <greg(at)turnstep(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-10-20 14:32:56 | Re: Controlling changes in plpgsql variable resolution |
Previous Message | Robert Haas | 2009-10-20 14:14:45 | Re: Could postgres be much cleaner if a future release skipped backward compatibility? |