"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Jan 10, 2008 5:00 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The spec's approach to datetime operations in general is almost totally
>> brain-dead, ...
> It's true that the spec fails to consider DST, in that it doesn't
> partition "day" and "second" intervals separately.
That's only one of the ways in which they ignore DST, and not even the
most important one --- my vote for the spectacularly bad omission is
that SET TIME ZONE only allows constant offsets from UTC.
> Whether the spec is braindead w.r.t intervals or not, Postgres is
> clearly giving the wrong answer.
Sure, but it's not clear that there *is* a right answer. As noted
upthread, a useful approximate answer can be better than no answer
at all.
> None of these comparisons are sane.
You can always refrain from making such comparisons, if you think they
are incapable of yielding useful answers.
This whole area is pretty messy, and I don't think that there is or can
be a simple uniform solution :-(. We need to tread carefully in
introducing new behaviors that we might regret later. So I'm not in
favor of inventing an interval division operator that just duplicates
functionality that's already there in a more-cumbersome notation.
We might want that operator back someday. Who even wants to argue that
the result datatype should be numeric? Dividing a three-component
quantity by another one doesn't sound to me like an operation that
naturally yields a scalar result.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
