Re: [HACKERS] Issues with generate_series using integer boundaries
Thom Brown <thom@linux.com>
From: Thom Brown <thom@linux.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, PGSQL Mailing List <pgsql-general@postgresql.org>
Date: 2011-06-17T14:22:33Z
Lists: pgsql-hackers
On 17 June 2011 04:44, Robert Haas <robertmhaas@gmail.com> wrote: > 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. I knew there'd be a much simpler way of solving this. Works for me. Thanks Robert. -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935 EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company