On 1 Feb 2011, at 21:26, Thom Brown wrote: > On 1 February 2011 01:05, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Thom Brown <t...@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! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
