Re: Bug 1500
От | Lyubomir Petrov |
---|---|
Тема | Re: Bug 1500 |
Дата | |
Msg-id | 4244811C.80502@sysmaster.com обсуждение исходный текст |
Ответ на | Re: Bug 1500 (Steve Crawford <scrawford@pinpointresearch.com>) |
Список | pgsql-hackers |
Steve Crawford wrote: >>So this bug actually brings the issue of interval to_char() >>formatting. Opinions? >> >> > >In digging around I discovered that it appears a decision was made to >remove to_char(interval) at the 8.1 release but I've been unable to >find the replacement for this functionality. This alarms me. > >Given the messages I've seen regarding to_char(interval), it's clearly >a function that is used. As an example, in our telephony systems >there is a column for start_time and for end_time. Billing involves a >sum(end_time-start_time) for the appropriate project/client/period. >Naturally, that interval needs to be displayed appropriately. > >The most common request I've seen (and it would be very helpful for me >as well) is the ability to fill the largest displayed time increment >with all remaining time in the interval. > >In other words when the total increment is 7 days, 7 hours, 28 >minutes, 12 seconds the desired output would be 10528 minutes 12 >seconds. Think phone-billing, race times, mission clocks, etc. > >So... > >1) Is there really a plan to eliminate to_char(interval)? > >2) If so, what is the replacement? > >3) If there isn't a replacement and it's just scheduled for >elimination, what harm was to_char(interval) causing to require its >removal and what's the best way to lobby for its retention and >improvement? > >Cheers, >Steve > >. > > > Steve, I am with you on this. The interval functionality is very useful and it will be bad if it gets eliminated. I believe that the best course of action is to keep the to_char(interval) but restrict the available format specifications (the textual representation specificators like Mon/Months). Regards, Lyubomir Petrov
В списке pgsql-hackers по дате отправления: