>
> 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.
>
Tangential comment but have you considered emitting a warning (and/or log
entry) when you are 10,000-50,000 away from issuing the last available
number in the sequence so that some recognition exists that any code
depending on the sequence is going to fail soon?
Also, during sequence creation you know the integer type being used so that
maximum value is known and an overflow should not need to come into play (I
guess the trade-off is the implicit "try-catch" [or whatever mechanism C
uses] performance hit versus the need to store another full integer in the
data structure).
You could also give access to the "warning threshold" value so that the
developer can change it to whatever value is desired (with a meaningful
default of course).
David J.