Re: [GENERAL] Issues with generate_series using integer boundaries - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [GENERAL] Issues with generate_series using integer boundaries
Date
Msg-id BANLkTim8qzdYZdfHu6zpeY_Jqn8V58+DXA@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Issues with generate_series using integer boundaries  (Thom Brown <thom@linux.com>)
Responses Re: [GENERAL] Issues with generate_series using integer boundaries  (Thom Brown <thom@linux.com>)
Re: [GENERAL] Issues with generate_series using integer boundaries  ("David Johnston" <polobo@yahoo.com>)
Re: [GENERAL] Issues with generate_series using integer boundaries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown <thom@linux.com> wrote:
> On 9 February 2011 02:11, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> Quite right, but the commitfest manager isn't meant to be a substitute for
>>> one. Bug fixes aren't subject to the same restrictions of feature changes.
>>
>> Another option would be to add this here:
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items
>
> I've removed it from the commitfest because it really doesn't belong
> there, and I've added it to the open items list.

So, I finally got around to look at this, and I think there is a
simpler solution.  When an overflow occurs while calculating the next
value, that just means that the value we're about to return is the
last one that should be generated.  So we just need to frob the
context state so that the next call will decide we're done.  There are
any of number of ways to do that; I just picked what looked like the
easiest one.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: crash-safe visibility map, take five
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade using appname to lock out other users