Skip site navigation (1) Skip section navigation (2)

Re: Issues with generate_series using integer boundaries

From: Thom Brown <thom(at)linux(dot)com>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Issues with generate_series using integer boundaries
Date: 2011-02-01 23:08:55
Message-ID: AANLkTim7sgHDDcdFPnnyYBJGVLwdAXPuPpvDqyK4j63Z@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On 1 February 2011 21:32, Alban Hertroys
<dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> wrote:
> On 1 Feb 2011, at 21:26, Thom Brown wrote:
>
>> 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.
>
>
> 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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2011-02-01 23:12:44
Subject: Re: [PERFORM] Slow count(*) again...
Previous:From: Andrew DunstanDate: 2011-02-01 23:03:39
Subject: Re: [PERFORM] Slow count(*) again...

pgsql-general by date

Next:From: hlcborgDate: 2011-02-01 23:19:10
Subject: Re: Problem with encode () and hmac() in pgcrypto
Previous:From: Bruce MomjianDate: 2011-02-01 22:18:00
Subject: Re: Documentation enhancement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group