Re: Disallow arrays with non-standard lower bounds - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Disallow arrays with non-standard lower bounds
Date
Msg-id CAHyXU0xu-wMaPOFNGjnT=_RONmwKkDVW19NmfErNO5sp3Xgvaw@mail.gmail.com
Whole thread Raw
In response to Re: Disallow arrays with non-standard lower bounds  (Craig Ringer <craig@2ndquadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: nested hstore patch
Next
From: Mel Gorman
Date:
Subject: Linux kernel impact on PostgreSQL performance