Tom, Karel, > Hmm, if we want to support conversion like: > ÂÂÂÂÂÂ'43 hours 20 minutes' --> 'MI min' > how we should work with calendar INTERVAL units? For example 'month'? > ÂÂÂÂÂÂ'1 month 1 day' --> 'D days' > I think answer should be error message: "missing calendar unit 'month' > in output format"
Actually, there's a pretty well-defined boundary within interval types: year.month | day.hour.minute.second.millesecond This subtype boundary of intervals is even defined in the SQL spec. > Surely not. to_char for timestamps doesn't require that you output > every field of the value, and it shouldn't require that for intervals > either. That's an invalid comparison. There is no logical way to "roll up" timestamps into larger/smaller subtypes. There is with intervals. If you're arguing that this kink in the *useful* behavior of interval-->text conversion is confusingly inconsistent with what to_char does with other data types, and we should call the function something else, then I could potentially buy that (assuming that others agree). However, our proprietary functions are about being *useful*, not adhering to some unwritten de-facto standard. And I am, as someone who uses intervals heavily in applications, trying to define what the useful behaviour will be from a user's perspective. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
