On 1 February 2011 21:32, Alban Hertroys <dalroi@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 1 Feb 2011, at 21:26, Thom Brown wrote: > >> On 1 February 2011 01:05, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >>> Thom Brown <thom@xxxxxxxxx> 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 I don't quite understand why the code works. As I see it, it always returns a set with values 1 higher than the corresponding result. So requesting 1 to 5 actually returns 2 to 6 internally, but somehow it correctly shows 1 to 5 in the query output. If there were no such discrepancy, the upper-bound/lower-bound problem wouldn't exist, so not sure how those output values result in the correct query result values. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
