From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thom Brown <thom(at)linux(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Issues with generate_series using integer boundaries |
Date: | 2011-06-17 18:15:13 |
Message-ID: | 20925.1308334513@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-17 18:40:04 | Re: [HACKERS] Issues with generate_series using integer boundaries |
Previous Message | artacus | 2011-06-17 17:53:07 | Stumped on windowing |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-17 18:24:09 | Re: ALTER TABLE lock strength reduction patch is unsafe |
Previous Message | Robert Haas | 2011-06-17 17:37:52 | Re: 9.1beta2 / UNLOGGED + CHECK + INHERITS |