Re: PG 7.4 BETA 3: Bug in NULL arrays updating

From: Bertrand Petit <pgsql(at)phoe(dot)frmug(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: PG 7.4 BETA 3: Bug in NULL arrays updating
Date: 2003-09-28 02:26:13
Message-ID: 20030928042613.B77633@memo.frmug.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Radziej 2003-09-29 16:50:17 bytea and vacuum analyze on postgresql 7.3.4
Previous Message Eric Ridge 2003-09-28 01:59:25 Re: Can't Build 7.3.4 on OS X