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

On Mon, Apr 1, 2013 at 6:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Mar 26, 2013 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Well, you could easily change array_ndims() to error out if ARR_NDIM()
>>> is negative or more than MAXDIM and return NULL only if it's exactly
>>> 0.  That wouldn't break backward compatibility because it would throw
>>> an error only if fed a value that shouldn't ever exist in the first
>>> place, short of a corrupted database.  I imagine the other functions
>>> are amenable to similar treatment.
>>
>> I haven't looked at the patch in detail, but I thought one of the key
>> changes was that '{}' would now be interpreted as a zero-length 1-D
>> array rather than a zero-D array.  If we do that it seems a bit moot
>> to argue about whether we should exactly preserve backwards-compatible
>> behavior in array_ndims(), because the input it's looking at won't be
>> the same anymore anyway.
>>
>> In any case, the entire point of this proposal is that the current
>> behavior around zero-D arrays is *broken* and we don't want to be
>> backwards-compatible with it anymore.  So if you wish to argue against
>> that opinion, do so; but it seems a bit beside the point to simply
>> complain that backwards compatibility is being lost.
>
> I don't think the current behavior is broken.  I found it
> counterintuitive at first, but then I got used to it.  It's reasonably
> self-consistent: arrays can't have empty dimensions, therefore the
> empty array is unique and dimensionless.  Is that the behavior I would
> have picked if I had designed the type?  No, it isn't.  I wouldn't
> have tried to support one-dimensional arrays and multi-dimensional
> arrays in the same data type either, nor would I have supported
> non-default lower bounds.  But all of those ships have sailed, and the
> time to change them is not after people have spent 10 years building
> applications that work with the current behavior.  If we want to
> introduce a new type with different, perhaps better, behavior, well, I
> think that might be a fine idea.  But I *don't* think imposing a hard
> compatibility break on users of arrays is a good idea.

100% agree.  Also huge +1 on your backwards compatibility comments
upthread -- couldn't agree more.  My $company just wrapped up a one
year porting effort to 9.2 from *8.1* due to compatibility issues.

If you want custom array behaviors, creating a type is probably the
best way unless it can be 100% proven that this will not break code.

merlin