Isaac Morland <isaac.morland@gmail.com> writes:
> I've attached a patch for this. Turns out there was a comment in the source
> explaining that there is no interval_abs because it's not clear what to
> return; but I think it's clear that if i is an interval the larger of i and
> -i should be considered to be the absolute value, the same as would be done
> for any type; essentially, if the type is orderable and has a meaningful
> definition of unary minus, the definition of abs follows from those.
The problem with that blithe summary is the hidden assumption that
values that compare "equal" aren't interesting to distinguish. As
the discussion back in 2009 pointed out, this doesn't help you decide
what to do with cases like '1 month -30 days'::interval. Either answer
you might choose seems pretty arbitrary --- and we've got more than
enough arbitrariness in type interval :-(
For similar reasons, I find myself mighty suspicious of your proposal
to change how max(interval) and min(interval) work. That cannot make
things any better overall --- it will only move the undesirable results
from one set of cases to some other set. Moreover your argument for
it seems based on a false assumption, that the input values can be
expected to arrive in a particular order. So I'm inclined to think
that backwards compatibility is sufficient reason to leave that alone.
If we wanted to make some actual progress here, maybe we should
reconsider the definition of equality/ordering for interval, with
an eye to not allowing two intervals to be considered "equal" unless
they really are identical. That is, for two values that are currently
reported as "equal", apply some more-or-less-arbitrary tiebreak rule,
say by sorting on the individual fields left-to-right. This would be
very similar to type text's rule that only bitwise-equal strings are
really equal, even if strcoll() claims otherwise. I am not sure how
feasible this idea is from a compatibility standpoint, but it's
something to think about.
regards, tom lane