From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)MIT(dot)EDU>, Joe Conway <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inconsistent behavior on Array & Is Null? |
Date: | 2004-04-02 19:31:25 |
Message-ID: | 877jwykwhe.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> That would break even more things, no?
>
> On the other hand, it'd get rid of the problem that we presently face
> with dump/restore of arrays that don't have lower bound 1. Because
> pg_dump doesn't do anything to mark such values, they'll end up with
> lower bound 1 after reload anyway. The fact that we haven't heard lots
> of squawks about that suggests to me that not many people are using such
> arrays at present ...
You have to be using not only arrays, but the new 7.4 functions provided to
manipulate them. In fact I think you have to be using array_prepend
specifically. But even there since it's not a mutator it's really not that
surprising that the elements of the brand new array it's returning should have
new indexes.
In fact I suspect there are more people with hidden bugs where they depend on
arrays starting at 1. This type of bug is insidious since it's hard to test
for, your application might never generate an array with a lower bound other
than 1 until someone adds some new code using array_prepend somewhere and all
of the sudden you get strange behaviours from unrelated code.
I can have the honour of being the first squawker like you describe, but my
problem was only evidence that having such non-normalized arrays at all was
surprising. I was using int_aggregate.c which generates non-standard arrays
with lower bounds of 0. My code assumed array_upper()+1 == length. After I
dumped and restored all my counts were off by one.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2004-04-02 19:33:26 | Re: GiST future |
Previous Message | Tom Lane | 2004-04-02 19:28:02 | Re: Better support for whole-row operations and composite types |