On Tue, 27 Jul 2004, Tom Lane wrote:

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

Tom Lane wrote:
I think that even once we support NULL array elements, they should be
explicitly requested -- i.e. throwing an error on non-rectangular input
is still the right thing to do. I haven't suggested that in the past
because of the backward-compatibility issue, but maybe now is the time
to bite the bullet.

If you think this qualifies as a bug fix for 7.5, I can take a look at
it next week.

Joe

---------------------------(end of broadcast)---------------------------
TIP 3: 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