Re: '1 year' = '360 days' ????
От | Bruno Wolff III |
---|---|
Тема | Re: '1 year' = '360 days' ???? |
Дата | |
Msg-id | 20041024041557.GA16121@wolff.to обсуждение исходный текст |
Ответ на | Re: '1 year' = '360 days' ???? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: '1 year' = '360 days' ????
|
Список | pgsql-general |
On Sat, Oct 23, 2004 at 23:36:05 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > We don't have to have this particular sorting decision, we just have > to have *some* unique sorting order. In particular, if we want to say > that two interval values are not equal, we have to be able to say which > one is less. For instance, "compare the months first and only if equal > compare the seconds" would work fine from the point of view of btree. > It's just that that leads to a sort order that users will probably not > like very much. One way to do comparisons is to use a mapping f(m,s) => R and compare (m1,s1) and (m2,s2) by comparing f(m1,s1) and f(m2,s2) and break ties by comparing say m1 and m2. This will work as long as f(m,s1) = f(m,s2) implies s1 = s2. It will probably be desirable to use a subset of these mappings where f(m,s) = g(m) + h(s). In fact the current system uses this with g(m) = 30*24*60*60*m and h(s) = s (but without the tiebreak that compares m values). Because of the way intervals work, I think you want to use an ordering generated like that you want to use something of the form f(m,s) = C1*m + C2*s. I also think that treating a month as 30 days and having round numbers is better than using something like 1/12 a solar year in seconds. So I think the best plan is to do things as they are now, except for adding a tie breaker just using months or seconds for when both intervals give the same number of seconds when treating months as 30 days, but have a different number of months.
В списке pgsql-general по дате отправления: