From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | alex(at)sunrise(dot)radiostudiodelta(dot)it, pgsql-bugs(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Subject: | Re: Bug #443: Problem with time functions. |
Date: | 2001-09-17 06:33:07 |
Message-ID: | 3BA59923.20CCEFAE@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> > Hmm. The underlying math works:
...
> "Works" is in the eye of the beholder, perhaps.
Of course ;)
> ... I would think that the
> difference of two times should be an interval (which would allow the
> sum() to work, since we have sum(interval)). But there is no
> time-minus-time operator. What actually appears to be happening is that
> the system casts the second time to an interval and then applies the
> time-minus-interval operator, yielding a time. There is no sum(time)
> aggregate, and shouldn't be IMHO.
>
> In short, I think the missing piece is not sum(time) but
> time-minus-time. Maybe that's what you think too, but it wasn't clear.
Well, I'd have been willing to think that, if I had known that.
> BTW, I'm unconvinced that an implicit cast from time to interval is a
> good idea... what's the point of maintaining a datatype distinction
> between timestamp-like types and interval-like types if we will allow
> implicit casts across that boundary?
I'm not certain whether this was to fix a particular issue or just
proactive mucking around.
Either way, a time-time operator seems like a good idea, until proven
otherwise. Will try to get it on my list for the current work.
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2001-09-17 11:45:28 | Bug #453: |
Previous Message | Thomas Lockhart | 2001-09-17 06:26:31 | Re: dynamic-static date once again |