On Tue, Aug 18, 2009 at 10:42, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Alex Hunsaker <badalex@gmail.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
