[ cc'ing pghackers in case anyone wants to object ]
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right now I think the sanest behavior would be to throw an error on
>> non-rectangular input. Once we have support for null elements in
>> arrays, however, it would arguably be reasonab
Tom Lane wrote:
Right now I think the sanest behavior would be to throw an error on
non-rectangular input. Once we have support for null elements in
arrays, however, it would arguably be reasonable to pad with NULLs
where needed, so that the above would be read as
{{1,2},{2,3},{4,NULL}}
On Tue, 27 Jul 2004, Tom Lane wrote:
> Right now I think the sanest behavior would be to throw an error on
> non-rectangular input. Once we have support for null elements in
> arrays, however, it would arguably be reasonable to pad with NULLs
> where needed,
>
I'm just forwarding a report men
Kris Jurka <[EMAIL PROTECTED]> writes:
> Casting strings to multidimensional arrays yields strange results.
array_in has fairly bizarre behavior when presented with non-rectangular
input data, such as your examples:
> jurka=# SELECT '{{1,2},{2,3},{4}}'::int[][];
> jurka=# SELECT '{{1},{2,3},{4,5
Kris Jurka <[EMAIL PROTECTED]> writes:
> Are you considering NULL padding arrays constructed with the
> ARRAY[] syntax?
Don't think anyone's really thought about it.
> we should consistently pad with 0 instead of sometimes padding and sometimes
> truncating.
"Pad with 0" is a meaningless conce
Casting strings to multidimensional arrays yields strange results. In one
case there are discard values and the other a value magically appears.
Trying both of these with the array[] constructor syntax yields the
expected:
ERROR: multidimensional arrays must have array expressions with match
