Re: Disallow arrays with non-standard lower bounds

On 01/14/2014 12:33 AM, Craig Ringer wrote:
> On 01/14/2014 12:40 AM, Merlin Moncure wrote:
>> 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).
> You're far from the only one, too. Until last year I was still seeing
> people saying they "can't" upgrade because of this. OTOH, that was a
> sudden and drastic change, with no BC switch like the removal of
> implicit joins had, that affected wide swaths of code. Lets not do that
> again.
>
> Removal of lower bounds for arrays is unlikely to even get noticed by
> the vast majority of users, and can be done progressively with BC features.
>
> The real issue IMO is how to get those few to stop using it so it can be
> truly removed. Past experience has shown that people just turn the
> compatibility flag on and forget they're using the deprecated feature.
> If there are warnings they'll silence them in their application and
> still forget they're using the deprecated feature. If there are log
> messages, they'll probably turn logging detail down to hide them and
> STILL forget they're using the deprecated feature.
>
> Then whine about it three years later when it gets removed.
>
> So I guess the question is: Is it worth all that hassle to remove a
> misfeature you have to go out of your way to use? Is support for non-1
> lower bounds stopping us from doing something useful and important? Or
> is it just an irritation that it exists?
>
Let's just add user defined operator for '[]' (weirdly-positioned but
2 argument, almost infix :) ) and add that to JSON arrays to get
0-based ones into poastgresq ;)

Cheers

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ