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:52:24 |
Message-ID: | 21726.1308336744@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:
> On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Oh, good 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.
Yeah, I can't get excited about it either; restructuring that code
enough to avoid an error seems like a lot more work than the case is
worth. Maybe someday somebody will hit the case in practice and then
be motivated to work on it, but in the meantime ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2011-06-17 19:42:43 | Re: 2 questions re RAID |
Previous Message | Robert Haas | 2011-06-17 18:40:04 | Re: [HACKERS] Issues with generate_series using integer boundaries |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-06-17 18:54:35 | Re: [v9.2] Start new timeline for PITR |
Previous Message | Tom Lane | 2011-06-17 18:44:13 | Re: ALTER TABLE lock strength reduction patch is unsafe |