Skip site navigation (1) Skip section navigation (2)

Re: Bad interval conversion?

From: Alex Hunsaker <badalex(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: depesz(at)depesz(dot)com, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Bad interval conversion?
Date: 2009-08-18 19:36:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Tue, Aug 18, 2009 at 12:07, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Throwing overflow errors doesn't seem very nice either, especially not
> for values that worked just fine before 8.4.

I just checked both 8.3.7 and 8.2.13 give:
# select '4817191.623 ms'::interval;
(1 row)

> Seems like a proper fix would involve doing some modulo arithmetic to be
> sure that we add the integral seconds to the seconds field and only a
> fraction to the fsec field.

Ok I looked around at the other fsec assignments in adt/ and did not
see any that were not treating them as fractional correctly.  This
seems to be the only case.  Anywho is the below more what you
expected? (I decided to do it for the floating point case as well...)

With this patch I get (it also passes a make check):
# select '4817191.623 ms'::interval;

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

                                        case DTK_MILLISEC:
+                                               tm->tm_sec += val / 1000;
+                                               val = val % 1000;
                                                *fsec += rint((val +
fval) * 1000);

Attachment: blah.patch
Description: text/x-patch (380 bytes)

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2009-08-18 19:41:39
Subject: Re: Bad interval conversion?
Previous:From: Tom LaneDate: 2009-08-18 18:07:24
Subject: Re: Bad interval conversion?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group