Re: age() function documentation
От | Peter Eisentraut |
---|---|
Тема | Re: age() function documentation |
Дата | |
Msg-id | Pine.LNX.4.30.0104121851220.1148-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: age() function documentation (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | pgsql-hackers |
Thomas Lockhart writes: > > b) date substraction not implemented at all (it does date - integer) > > No, and changing what it *does* do has ramifications. Okay, I see there's 'date - date' after all. But 'date - date' should still return some kind of time interval, not an integer. Of course changes have ramification, but standing still does, too. > > d) intervals not implemented per spec > > ? Why would you say this? Because it's a fact. SQL has year to month intervals and day to second intervals, no all encompassing interval. It sounds stupid at first, but a lot of weird little definitional problems would go away if we had support for these. Months and years are "unstable" units when used together with days, minutes, etc. but they are a consistent system when only used among themselves. The current implementation already reflects this by making "time" and "month" different struct members, so I guess what lacks a little are user-accessible means of controlling which gets used. The difference is between age() and timestamp subtraction is in fact that the former returns a year to month interval and the other a day to second interval. But in the current implementation the only effective difference is that the interval is diplayed differently, which is a confusing concept because data values are not defined by their representation but by their value. > Please be specific about what you think needs changing, and why. And > I'll actually be able to pay attention after the 7.1 release ;) Fix^H^H^HEnhancing the interval type up to spec would really go a long way I think. We could redefine Interval like struct Interval { bool is_month_to_year; union { double seconds; struct my { int32 months; int32 years; } } } This would make it mostly compatible to its current behaviour. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: