Re: Bad interval conversion?

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