When updating a NULL cell which is an array of something,
setting an adressed member of a non existent array, the value of the
cell is not changed.

---------
t
(1 row)

-----+-----
1 |
(1 row)

---------
t
(1 row)

------------------------------------------------------------------------
PostgreSQL 7.4beta3 on i386-unknown-freebsd4.5, compiled by GCC 2.95.3
(1 row)

I expected that the bar column be set to {"Blah"}. After a few
seconds of thought, I pictured the updating as setting the first
member of the NULL array (NULL[0] := 'Blah'). Ouch that looks like a
"null pointer". So maybe the non updating of bar is correct. But in
this case an error or a warning should be raised.

--
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Bertrand Petit <pgsql (AT) phoe (DOT) frmug.org> writes:
Assigning to a member of a NULL array has always yielded another NULL
array. While I've never been particularly satisfied with that behavior
either, it has some logical symmetry to it. What do you think the
behavior ought to be? (In particular, if a non-null array should
result, where do we get its dimensions and subscripts from?)

regards, tom lane

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

Tom Lane wrote:
I think the behavior is correct. An analogy I is text concatenation. If
I concatenate 'a' to NULL::text, I get NULL. But if I concatenate 'a' to
an empty text value, '', I get 'a'.

Similarly if you assign to an element of an empty array, '{}', you get
an array with the one appended element. Not sure if this works pre-7.4
though -- I know I made some changes related to this, but I forget the
exact details.

Joe


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

On Wed, Sep 24, 2003 at 12:09:52AM -0400, Tom Lane wrote:
My view on this is that the problem should be simplified by
throwing an error and a notice reminding the user to use coalesce().

Another view might be that, on an update operation, a new
array be created as you sugested. The type and number of dimensions of
the new array would be those of the updated column. All array members
would be NULLs except the explicitely referenced members. The
referenced subscripts would be the upper bounds for the dimensions
sizes.

Regards,
Bertrand.

--
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org