On 5/20/06, Tom Lane <tgl@xxxxxxxxxxxxx> 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
