Обсуждение: Interval overflow?
Is this expected behavior or a bug?
=> select version();
version
------------------------------------------------------------------------------------------------
PostgreSQL 8.2.4 on i386-portbld-freebsd6.2, compiled by GCC cc (GCC)
3.4.6 [FreeBSD] 20060305
(1 row)
=> select '2000000000 hours'::interval + '2000000000 hours'::interval;
?column?
--------------------------
-1124095576:01:49.551616
(1 row)
Regards,
Jeff Davis
On Jun 29, 2007, at 16:07 , Jeff Davis wrote: > Is this expected behavior or a bug? Bug. In general the range checking in the date time code can definitely be improved. Michael Glaesemann grzm seespotcode net
Michael Glaesemann <grzm@seespotcode.net> writes:
> On Jun 29, 2007, at 16:07 , Jeff Davis wrote:
>> Is this expected behavior or a bug?
> Bug. In general the range checking in the date time code can
> definitely be improved.
Apparently Jeff's using enable-integer-datetimes; what I see is
regression=# select '2000000000 hours'::interval + '2000000000 hours'::interval;
?column?
------------------
2147483647:00:00
(1 row)
It looks like his case is overflowing the int8 microseconds field of
the interval. On my machine, the seconds field is double so it does not
overflow, but interval_out tries to convert the computed hours value
to int32, and *that* overflows.
The best we can do for Jeff is throw an error in interval addition.
In the float case it could be wished that we could print any result
we can store ...
regards, tom lane
On Fri, 2007-06-29 at 17:31 -0400, Tom Lane wrote:
> It looks like his case is overflowing the int8 microseconds field of
> the interval. On my machine, the seconds field is double so it does not
> overflow, but interval_out tries to convert the computed hours value
> to int32, and *that* overflows.
>
> The best we can do for Jeff is throw an error in interval addition.
That sounds reasonable to me.
> In the float case it could be wished that we could print any result
> we can store ...
>
Agreed.
Regards,
Jeff Davis