Joe Conway <mail@joeconway.com> writes:
> ... 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?
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