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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
