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

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Дата
Msg-id 87oco26t81.fsf@hi-media-techno.com
обсуждение исходный текст
Ответ на Re: Could postgres be much cleaner if a future release skipped backward compatibility?  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Could postgres be much cleaner if a future release skipped backward compatibility?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Controlling changes in plpgsql variable resolution