Re: Disallow arrays with non-standard lower bounds

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, Jim Nasby <jim(at)nasby(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Disallow arrays with non-standard lower bounds
Date: 2014-01-13 16:40:57
Message-ID: CAHyXU0xu-wMaPOFNGjnT=_RONmwKkDVW19NmfErNO5sp3Xgvaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jan 12, 2014 at 4:38 AM, Craig Ringer <craig(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mel Gorman 2014-01-13 16:42:21 Linux kernel impact on PostgreSQL performance
Previous Message Andrew Dunstan 2014-01-13 16:26:42 Re: nested hstore patch