Re: [HACKERS] Issues with generate_series using integer boundaries

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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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