From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Statistical Lacunae in Interval type |
Date: | 2004-07-12 15:10:34 |
Message-ID: | 24447.1089645034@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The problem is that an interval datum already implies the units, so in
> order to allow interval * interval we would have to add a new type
> "interval squared", which would probably be considered to be a bit
> foolish.
Not only foolish but complicated. Remember that interval internally
is "N months plus X seconds" (where N is integral but X needn't be).
To avoid losing information, a product datatype would have to look
something like "N months-squared plus X months-seconds plus Y
seconds-squared", which offers no intuition whatever about how to
operate on it. I doubt there's even a unique way to define
square-rooting this.
Add on top the fact that we really need to change interval to be
"M months plus N days plus X seconds" to solve the ever-popular
daylight-savings-transition issues, and a product datatype would
get out of hand altogether.
When I said "mash it down to seconds first", I was speaking very
literally...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2004-07-12 15:44:55 | Re: Statistical Lacunae in Interval type |
Previous Message | Peter Eisentraut | 2004-07-12 14:57:45 | Re: Statistical Lacunae in Interval type |