Re: PG 7.4 BETA 3: Bug in NULL arrays updating - Mailing list pgsql-bugs

From Bertrand Petit
Subject Re: PG 7.4 BETA 3: Bug in NULL arrays updating
Date
Msg-id 20030928042613.B77633@memo.frmug.org
Whole thread Raw
In response to Re: PG 7.4 BETA 3: Bug in NULL arrays updating  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Sep 24, 2003 at 12:09:52AM -0400, Tom Lane wrote:
>
> 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?)

    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

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pthread.h
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] bug in clusterdb script