On Thu, Jun 20, 2013 at 2:58 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Thu, Jun 13, 2013 at 11:57:27AM -0500, Merlin Moncure wrote:
>> >> But, couldn't that be solved by deprecating that function and
>> >> providing a more sensible alternatively named version?
>> >
>> > And what would you name that function? array_dims2? I can't think of
>> > a name that makes the difference in behaviour apparent. Can you
>> > imagine the documentation for that?
>>
>> I don't know the answer to that, but I think it's hard to argue that
>> deprecating and documenting a few functions is a heavier burden on
>> your users than having to sift through older arcane code before
>> upgrading to the latest version of the database. We're not the only
>> ones stuck with lousy old functions (C finally ditched gets() in the
>> 2011 standard). I also happen to think the current array_api function
>> names are not particularly great (especially array_upper/array_lower)
>> so I won't shed too many tears.
>
> Sorry to be late on this, but are you saying people have code that is
> testing:
>
> select array_dims('{}'::int[])
>
> for a NULL return, and they would need to change that to test for zero?
Kinda -- what I'm saying is you just don't go around changing function
behaviors to make them 'better' unless the affected behavior was
specifically reserved as undefined. The fact is nobody knows how many
users will be affected and the extent of the ultimate damage (pro tip:
it's always more and worse than expected); I'm astonished it's even
being considered.
merlin