Re: Bad interval conversion?

On Tue, Aug 18, 2009 at 10:42, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alex Hunsaker <badalex(at)gmail(dot)com> writes:
>> It only happens if you have integer date times on... seems to have
>> gotten introduced by
>> http://archives.postgresql.org/pgsql-committers/2008-03/msg00406.php
>
> Uh, no, fsec_t was int32 before that (look towards the bottom of the
> diff).  I'm fairly dubious that fixing it as you suggest is a one-liner
> --- the width of fsec_t is something that seems likely to propagate all
> over.  A narrower fix for whatever this specific problem is seems safer.

(not to mention it probably breaks ecpg ...)

I saw:
typedef int32 fsec_t;
vs
typedef double fsec_t;

and thought hrm... that looks odd..

Ok well we can add overflow checks where we need-em. If you don't
think the attached patch is horridly ugly- im willing wade through the
uses of fsec and apply something similar where we need them.
(DTK_SECOND at the very least, but fsec_t stuff is scattered all
through adt/)

*** a/src/backend/utils/adt/datetime.c
--- b/src/backend/utils/adt/datetime.c
***************
*** 2987,2993 **** DecodeInterval(char **field, int *ftype, int nf, int range,

case DTK_MILLISEC:
#ifdef HAVE_INT64_TIMESTAMP
! *fsec += rint((val + fval) * 1000);
#else
*fsec += (val + fval) * 1e-3;
#endif
--- 2987,3001 ----

case DTK_MILLISEC:
#ifdef HAVE_INT64_TIMESTAMP
! /*
! * fval is unused or re-initialized if it is
! * needed again */
! fval = rint((val + fval) * 1000);
!
! if (fval < INT_MIN || fval > INT_MAX)
! return DTERR_FIELD_OVERFLOW;
!
! *fsec += fval;
#else
*fsec += (val + fval) * 1e-3;
#endif