On 4/1/13 8:58 AM, Merlin Moncure wrote:
> 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.
+1, and FWIW I'd love to see a new, cleaner array implementation. My beefs with the current system:
- Adjustable lower bound is *way* more trouble than it's worth (does anyone actually have a use-case for supporting
it?)
- Need to be able to tell if an array is actually empty/null, which is not the same as an array where all elements are
null
- Enforced dimensions would be nice, though I can't say it's that big a deal
- Not sure that special casing 1 dimension arrays would be worth it... perhaps enforced dimensions solve whatever
problemsexist there