On Fri, Oct 30, 2009 at 01:09:30PM -0700, Scott Bailey wrote:
> Sam Mason wrote:
> >My personal feeling is that when you provide any ordering operator and
> >negation you can easily provide an absolute value operator. We've
> >already (somewhat arbitrarily) decided that one of '1month -30days' and
> >'-1month 30days) is "greater" than the other, so why not provide an
> >operator that returns the "greater" of an interval value and its own
> >negation?
>
> Technically, greater doesn't arbitrarily decide one is greater than the
> other. It determines the two are equivalent and (correctly) chooses the
> leftmost one.
where "correctly" has various provisos attached.
> I think it is important to separate the concept of an interval with
> addition of an interval with a timestamp. By (the interval type's)
> definition a day is 24 hours, a month is 30 days, a year is 365.25 days.
When I was saying "arbitrary" above; it was in choosing these numbers.
They're reasonable defaults that do the right thing most of the time,
but it's possible to have other values that would give better results in
certain (rare) situations. I don't think we want to go changing things
though, the current values are what most people expect.
> To say that extract epoch can determine the number of seconds in an
> interval, while saying that you can not determine the absolute value of
> an interval is not logical. Either you can do both or you can do neither.
Yes, I agree.
> perhaps things like extract epoch and abs
> should exhibit different behaviors when the month part is used.
>
> mos | days
> 11 | 330
> 12 | 365.25
You mean that it should trunc() the result of the months part to
complete days? Instead of doing:
result += ((double) DAYS_PER_YEAR * SECS_PER_DAY) * (interval->month / MONTHS_PER_YEAR);
it should be doing:
result += trunc((interval->month / MONTHS_PER_YEAR) * DAYS_PER_YEAR) * SECS_PER_DAY;
? Not sure if a change such as this could be made though.
--
Sam http://samason.me.uk/
