Re: Issues with generate_series using integer boundaries
От | Alban Hertroys |
---|---|
Тема | Re: Issues with generate_series using integer boundaries |
Дата | |
Msg-id | CB0F669D-83CB-4ADA-90D4-9D89B9AADF6D@solfertje.student.utwente.nl обсуждение исходный текст |
Ответ на | Re: Issues with generate_series using integer boundaries (Thom Brown <thom@linux.com>) |
Ответы |
Re: Issues with generate_series using integer boundaries
|
Список | pgsql-general |
On 1 Feb 2011, at 21:26, Thom Brown wrote: > On 1 February 2011 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Thom Brown <thom@linux.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. That could actually be used as a feature to create a repeating series. A bit more control would be useful though :P Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4d487c1211731974314558!
В списке pgsql-general по дате отправления: