Re: Disallow arrays with non-standard lower bounds

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Disallow arrays with non-standard lower bounds
Дата
Msg-id CAHyXU0xu-wMaPOFNGjnT=_RONmwKkDVW19NmfErNO5sp3Xgvaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Disallow arrays with non-standard lower bounds  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: Disallow arrays with non-standard lower bounds  (Jim Nasby <jim@nasby.net>)
Re: Disallow arrays with non-standard lower bounds  (David Fetter <david@fetter.org>)
Re: Disallow arrays with non-standard lower bounds  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> Implicit casts to text, anybody?

This backward compatibility break orphaned the company I work for on
8.1 until last year and very nearly caused postgres to be summarily
extirpated (only rescued at the last minute by my arrival). It cost
hundreds of thousands of dollars to qualify a sprawling java code base
so that it could be moved back into a supported version.  Breaking
compatibility sucks -- it hurts your users and costs people money.
Hacking type casts may not have been a mistake, but the arbitrary
introduction of the breakage certainly was.

This project has no deprecation policy, and I'd argue we'd need one
before considering breaking changes.  For example, maybe we could pull
out an occasional release for longer term support to help users that
caught out.   But really, the better way to go IMNSHO is to take a
hard line on compatibility issues pretty much always -- consider the
case of libc and win32 api.  There are certain limited exceptions to
this rule -- for example security problems or gross violations of the
standard (bringing row-wise comparison to spec comes to mind as an
example of that).

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: nested hstore patch
Следующее
От: Mel Gorman
Дата:
Сообщение: Linux kernel impact on PostgreSQL performance