Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Tom Lane <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
