From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Issues with generate_series using integer boundaries |
Date: | 2011-02-01 20:26:34 |
Message-ID: | AANLkTinwULWX_cChuFA-XkSBqL7zQJ1EpT132QQ-x6NL@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 1 February 2011 01:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thom Brown <thom(at)linux(dot)com> writes:
>> I've noticed that if I try to use generate_series to include the upper
>> boundary of int4, it never returns:
>
> I'll bet it's testing "currval > bound" without considering the
> possibility that incrementing currval caused an overflow wraparound.
> We fixed a similar problem years ago in plpgsql FOR-loops...
Yes, you're right. Internally, the current value is checked against
the finish. If it hasn't yet passed it, the current value is
increased by the step. When it reaches the upper bound, since it
hasn't yet exceeded the finish, it proceeds to increment it again,
resulting in the iterator wrapping past the upper bound to become the
lower bound. This then keeps it looping from the lower bound upward,
so the current value stays well below the end.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2011-02-01 21:05:29 | Re: Some Problems - Shall I reinstall the DB? |
Previous Message | John R Pierce | 2011-02-01 20:25:26 | Re: yum repo problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Hotchkiss | 2011-02-01 20:51:47 | Re: Authentication Enhancement Proposal |
Previous Message | Simon Riggs | 2011-02-01 20:25:35 | Re: Error code for "terminating connection due to conflict with recovery" |