Re: Bad interval conversion?

On Tue, Aug 18, 2009 at 10:42, Tom Lane wrote:
> Alex Hunsaker  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