On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> +1 for this solution.
>
> BTW, there was some mention of changing the timestamp versions of
> generate_series as well, but right offhand I'm not convinced that
> those need any change. I think you'll get overflow detection there
> automatically from the functions being used --- and if not, it's a
> bug in those functions, not in generate_series.
Maybe not, because those functions probably throw an error if an
overflow is detected, and that's not really correct. By definition,
the second generate_series() is the point at which we should stop
generating, and that point has to be within the range of the
underlying data type, by definition. So if an overflow occurs, that's
just another way of saying that we've certainly gone past the stop
point and needn't generate anything further. The error is an artifact
of the method we've used to generate the next point.
I'm not sure how much energy it's worth expending on that case. Using
really large dates may be less common that using values that strain
the range of a 4-byte integer. But it might at least be worth a TODO.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company