Re: Some array semantics issues

Tom Lane wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>>Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>
>>>Well, in that case what do you think about
>>>{{1,2},{3,4},{5,6},{7,8}}
>>>vs
>>>{{1,2,3,4},{5,6,7,8}}
>
>>In the first case the first element is {1,2} and in the second case the first
>>element is {1,2,3,4} so from my point of view there's no way these are the
>>same.
>
> Well, then I think we're converging on agreement that array comparison
> should always take into account the number of dimensions and the axis
> lengths. What seems still in question is whether to compare or ignore
> the axis lower bounds.
>
> I'd argue that ordinary equality should include the lower bounds, but
> I'm willing to provide a separate operator (or whole btree opclass
> if people want it) that ignores the lower bounds. We just need a name.
> Maybe ~=, ~<, etc?

A couple of thoughts based on the last time I read SQL2003 WRT arrays.

First, the spec only allows arrays to have a lower bound of 1. That
requirement simplifies a whole lot of things. I don't think that many
people actually depend on other than 1 as a lower bound (or at least if
they do, they weren't dumping and reloading those databases prior to
8.0) -- maybe given other possibly non-backward compatible changes for
NULLs, we should also change this?

Second, the spec does not really directly allow for multidimensional
arrays. What it does allow is nesting of arrays. So as Greg states,
{1,2} is clearly a different array than {1,2,3,4}. I had been thinking
that when (if?) the array literal parser and related infrastructure is
rewritten, it should be done so that arrays-as-array-elements are
processed similar to any scalar element (and perhaps tuples as array
elements as well). My hope was that eventually anyarray I/O functions
could eliminate the need to create an array type for every data type you
wanted to use as an array element.

Joe