Re: No stddev() for interval?

From: "Nikolay Samokhvalov" <samokhvalov(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: iz(at)sai(dot)msu(dot)ru, "Brendan Jurd" <direvus(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: No stddev() for interval?
Date: 2006-05-20 21:46:08
Message-ID: e431ff4c0605201446x575a749cve2b493eb18d5abf0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 5/20/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> If the intervals are all expressed in seconds then sure, the calculation
> is straightforward and useful. I'm wondering what happens when nonzero
> values of days and months get in there.

Ah!
Maybe the reason for such thoughts lies in nature of postgres intervals.
SQL:2003 standard paper says:
'There are two classes of intervals. One class, called year-month
intervals, has an express or implied datetime
precision that includes no fields other than YEAR and MONTH, though
not both are required. The other class,
called day-time intervals, has an express or implied interval
precision that can include any fields other than
YEAR or MONTH.'

So, the basic question is 'why Postgres allows to combine month and day?'
Actually, is it good idea?

If we have two separate interval types - we haven't the problem of '1
month VS 30 days' at all... And if we have no such a problem, we would
work with intervals as with numbers (I don't see the strong reason for
absense of stddev() and even variance() for INTERVAL YEAR TO MONTH,
INTERVAL DAY TO SECOND, INTERVAL MINUTE TO SECOND and so on).

--
Best regards,
Nikolay

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bob Pawley 2006-05-20 22:11:20 Read Write
Previous Message Nikolay Samokhvalov 2006-05-20 21:37:21 Re: No stddev() for interval?