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
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 |