Tom Lane wrote:
Sorry for the slow response -- I'm at the airport just heading home from
a marathon 30 day business trip.

I think producing another zero-dimensional result is the only way that
makes sense unless/until we change multidimensional arrays to really be
arrays of array-datatype elements. Right now they're two different things.

Yes -- I'll see if I can find the time over the next couple weeks while
home.

Joe

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Joe Conway <mail (AT) joeconway (DOT) com> writes:
Yow. Hope you get some time off...

On looking at the code, I notice that this somewhat-related case works:

regression=# select array[null::text[], null::text[]];
array
-------
{}
(1 row)

The reason is that null inputs are just ignored in ExecEvalArray. So
one pretty simple patch would be to ignore zero-dimensional inputs too.
This would have implications for mixed inputs though: instead of

regression=# select array['{}'::text[], '{a,b,c}'::text[]];
ERROR: multidimensional arrays must have array expressions with matching dimensions

you'd get behavior like

regression=# select array[null::text[], '{a,b,c}'::text[]];
array
-----------
{{a,b,c}}
(1 row)

Which of these seems more sane?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Tom Lane wrote:
Yeah, I just took a week. Next week I'm back to work and the week after
that I'm back to Germany for a few...

I'm not sure I love either. I would think both NULL and empty array
expressions should be disallowed in this scenario, i.e.:

regression=# select array['{}'::text[], '{a,b,c}'::text[]];
ERROR: multidimensional arrays must have array expressions with
matching dimensions

regression=# select array[NULL::text[], '{a,b,c}'::text[]];
ERROR: multidimensional arrays must have array expressions with
matching dimensions

In both cases you are trying to construct a multidimensional array with
inconsistent dimensions.

On the other hand, building an N-dimension array from entirely empty
array expressions should just produce an empty array, while using all
NULL expressions should produce an N-dim array full of NULLs.

But as I've opined before, all of this seems to me to be much cleaner if
arrays were always one-dimensional, and array elements could also be
nested arrays (per SQL 2003). If we said that the cardinality of the
nested array is an integral part of the datatype, then I think you would
have:

regression=# select array['{}'::text[], '{a,b,c}'::text[]];
ERROR: nested arrays must have array expressions with matching
dimensions

regression=# select array[NULL::text[], '{a,b,c}'::text[]];
array
-----------
{NULL, {a,b,c}}
(1 row)

So maybe this is the behavior we should shoot for now?

Joe

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Joe Conway <mail (AT) joeconway (DOT) com> writes:
Perhaps that's something to think about for 8.3, but it's clearly
infeasible for 8.2, to say nothing of the back branches. What I've
just committed does this:

* if all inputs are empty arrays, return an empty array (instead of failing)

* if mix of empty and nonempty arrays, raise error (same as before)

The case of NULL subarrays is a bit weird. In the back branches the
ARRAY[] construct was strict and would return a NULL array if any input
was NULL; I think it would be a bad idea to change that. The HEAD code
was simply skipping over NULL subarrays, which seemed like a good idea
at the time but on reflection is not so hot. What I've done is to make
it treat NULL subarrays as if they were empty subarrays.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster