Re: Interval aggregate regression failure (expected seems wrong)

On Nov 7, 2005, at 18:28 , Michael Paesold wrote:

> Ok, forgot. This is *without* integer-datetimes, RHEL 3 (Linux
> 2.4.21, glibc 2.3.2, gcc 3.2.3 20030502) on i686 (Xeon without
> x86-64).
>
>> I just ran make check on for PostgreSQL 8.1.0 on Mac OS X 10.4.3

Heh. I forgot, too ;) My test was also without integer-datetimes.

> [snip]
>> I didn't have any regression failures. I'd also expect we'd see a
>> lot more failures on the build farm if it were the case that it
>> was broken just on the platform that the expected results were
>> generated on. From a quick look at the current build farm
>> failures on HEAD and REL8_1_STABLE, it doesn't look like any of
>> the failures are failing here.
>
> I just started to wonder about buildfarm, too, but found that most
> build farm members have --enable-integer-datetimes. Could that be
> an explanation? Is it possible that the code is wrong with --enable-
> integer-datetimes?
>
> So what do you have in results/interval.out?
> @ 4 years 1 mon 9 days 28 hours 18 mins 23 secs seems wrong to me, no?
>

select avg(f1) from interval_tbl;
avg
-------------------------------------------------
@ 4 years 1 mon 9 days 28 hours 18 mins 23 secs
(1 row)

The point of the change to the interval datatype in 8.1 is to keep
track of months, days, and seconds (which in turn are represented as
hours, minutes and seconds). Previous releases tracked only months
and seconds. This has advantages for using intervals with dates and
timestamps that involve daylight saving time changes. Admittedly, it
looks odd at first, but it falls out of the change in behavior of the
interval datatype. There are two new functions, justify_days and
justify_hours, that you can use to put intervals into more
traditional forms.

http://developer.postgresql.org/docs/postgres/functions-datetime.html

Doesn't explain why you're getting a regression failure though.

Michael Glaesemann
grzm myrealbox com