## Re: [HACKERS] Interval aggregate regression failure

From: Bruce Momjian Bruce Momjian Michael Glaesemann , Tom Lane , Michael Paesold , PostgreSQL-patches Re: [HACKERS] Interval aggregate regression failure 2006-09-04 03:57:38 200609040357.k843vc810185@momjian.us (view raw or flat) 2006-09-03 11:51:46 from Michael Glaesemann  2006-09-03 19:25:06 from Bruce Momjian   2006-09-03 19:47:47 from Tom Lane    2006-09-04 01:07:58 from Bruce Momjian  2006-09-03 19:45:21 from Bruce Momjian   2006-09-03 22:52:29 from Michael Glaesemann    2006-09-04 01:07:21 from Bruce Momjian   2006-09-04 03:57:38 from Bruce Momjian    2006-09-05 01:14:50 from Bruce Momjian     2006-09-05 11:58:11 from Michael Glaesemann      2006-09-06 02:05:48 from Bruce Momjian pgsql-patches
```Bruce Momjian wrote:
> Michael Glaesemann wrote:
> >
> > On Sep 3, 2006, at 12:34 , Bruce Momjian wrote:
> >
> > > OK, I worked with Michael and I think this is the best we are going to
> > > do to fix this.  It has one TSROUND call for Powerpc, and that is
> > > documented.  Applied.
> >
> > As I was working up regression tests, I found a case that this patch
> > doesn't handle.
> >
> > select interval '4 mon' * .3 as product_h;
> >         product_h
> > -----------------------
> > 1 mon 5 days 24:00:00
> > (1 row)
> >
> > This should be 1 mon 6 days. It fails for any number of months
> > greater than 3 that is not evenly divisible by 10, greater than 3
> > months. Do we need to look at the month remainder separately?
>
> Another question.  Is this result correct?
>
> 	test=> select '999 months 999 days'::interval / 100;
> 	        ?column?
> 	-------------------------
> 	 9 mons 38 days 40:33:36
> 	(1 row)
>
> Should that be:
>
> 	 9 mons 39 days 16:33:36
>
> The core problem is that the combined remainder seconds of months and
> days is > 24 hours.

OK, updated patch.  It will fix the >=24:00:00 case because it cascades
up if the remainder number of seconds is greater or equal to one day.
One open item is that it still might show >24 hours if the seconds
computation combined with the remaning seconds >24 hours.  Not sure if
that should be handled or not.  If you fix that, you really are
cascading up because the resulting seconds might be less than the
computed value, e.g. result is 23:00:00, remainder is 02:00:00, cascade
up would be 1 day, 01:00:00.  I am unsure we want to do that.  Right
now, this will show 25:00:00.

--
Bruce Momjian   bruce(at)momjian(dot)us
EnterpriseDB    http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
```

Attachment: /pgpatches/interval
Description: text/x-diff (4.0 KB)

### pgsql-patches by date

 Next: From: Tom Lane Date: 2006-09-04 04:06:02 Subject: Re: [PATCHES] possible ecpg vpath build error Previous: From: Michael Glaesemann Date: 2006-09-04 03:57:32 Subject: Re: [PATCHES] possible ecpg vpath build error