Re: Bug 1500 - Mailing list pgsql-hackers

From Lyubomir Petrov
Subject Re: Bug 1500
Date
Msg-id 4244811C.80502@sysmaster.com
Whole thread Raw
In response to Re: Bug 1500  (Steve Crawford <scrawford@pinpointresearch.com>)
List 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 by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: lazy_update_relstats considered harmful (was Re: [PERFORM]
Next
From: Lyubomir Petrov
Date:
Subject: Re: Bug 1500