On Sun, Mar 24, 2013 at 10:02 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 03/20/2013 04:45 PM, Brendan Jurd wrote:
>> Incompatibility:
>> This patch introduces an incompatible change in the behaviour of the
>> aforementioned array functions -- instead of returning NULL for empty
>> arrays they return meaningful values. Applications relying on the old
>> behaviour to test for emptiness may be disrupted. One can
>
> As a heavy user of arrays, I support this patch as being worth the
> breakage of backwards compatibility. However, that means it certainly
> will need to wait for 9.4 to provide adequate warning.
I expect to lose this argument, but I think this is a terrible idea.
Users really hate it when they try to upgrade and find that they, uh,
can't, because of some application-level incompatibility like this.
They hate it twice as much when the change is essentially cosmetic.
There's no functional problems with arrays as they exist today that
this change would solve.
The way to make a change like this without breaking things for users
is to introduce a new type with different behavior and gradually
deprecate the old one. Now, maybe it doesn't seem worth doing that
for a change this small. But if so, I think that's evidence that this
isn't worth changing in the first place, not that it's worth changing
without regard for backwards-compatibility.
Personally, I think if we're going to start whacking around the
behavior here and risk inconveniencing our users, we ought to think a
little larger. The fundamental thing that's dictating the current
behavior is that we have arrays of between 1 and 6 dimensions all
rolled up under a single data type. But in many cases, if not nearly
all cases, what people want is, specifically, a one-dimensional array.If we were going to actually bite the bullet and
createseparate data
types for each possible number of array dimensions... and maybe fix
some other problems at the same time... then the effort involved in
ensuring backward-compatibility might seem like time better spent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
