Re: [PATCH] Exorcise "zero-dimensional" arrays (Was: Re: Should array_length() Return NULL)

On Thu, Jun 20, 2013 at 03:33:24PM -0500, Merlin Moncure wrote:
> On Thu, Jun 20, 2013 at 2:58 PM, Bruce Momjian <bruce(at)momjian(dot)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.

Well, I think the question is how many people have such arrays that will
be effected. If we don't do something, we live with this odd behavior
forever. We have been willing to make some bold decisions in the past
to improve user experience, and it mostly has worked out well. I
disagree that it is always worse than expected.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +