Re: Bug #443: Problem with time functions.

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

In response to

Browse pgsql-bugs by date

  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