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 mentioned on irc so I have no real personal
interest. The user was really just trying to figure out how it was
supposed to work, rather than requesting a particular behavior.
Are you considering NULL padding arrays constructed with the
ARRAY[] syntax? If not then this should definitely throw an error to
match that. If we plan on moving to consistent NULL padding, perhaps now
we should consistently pad with 0 instead of sometimes padding and sometimes
truncating. This is a change along the direction we're going even if it
is an intermediate behavior.
Doing some testing along these lines for different data types makes me
think this might not be the best idea, 0 and '' seem like reasonable
defaults for numeric/text data, but for some reason 2000-01-01 is the
default for a date, and I'm sure other data types have similar problems.
jurka=# select
'{{2001-01-01},{2001-02-02,2003-03-03},{2004-02-02,2004-04-04}}'::date[][];
date
---------------------------------------------------------------------------
{{2001-01-01,2000-01-01},{2001-02-02,2003-03-03},{2004-02-02,2004-04-04}}
Kris Jurka
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
