Re: Some array semantics issues

Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
>>Tom Lane <tgl@sss.pgh.pa.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