"Brendan Jurd" <[EMAIL PROTECTED]> writes: > I've been looking at the postgres interval implementation lately, and > I'm interested in putting together an improved implementation that > accords more closely with the SQL specification, in particular with:
Appealing to the SQL spec isn't going to take you very far in this argument, because the SQL spec itself is pretty broken in this area. In particular, the only reason that year-month vs day-second makes any sense is that they're pretending daylight savings doesn't exist. If you allow for DST transitions then the day/second multiplier isn't constant any more than the month/day multiplier is. (And then there are leap seconds...) I don't especially want to get into leap-second-aware timekeeping, because that'd practically destroy the ability to do calendar arithmetic at all. But DST awareness seems like a requirement to me. We just recently fixed "interval" to do something fairly plausible in that area, and I don't much want to backtrack. > It could be done without breaking existing applications; just > implement the two new interval types, and leave the old unified > interval in place as a deprecated type, then drop it after a few major > releases. Uh, not if all three types want to be called "interval", and I don't entirely see how you maintain spec compliance without that. In any case, actually *dropping* support for the existing interval behavior is a way harder sell than just adding something more spec-like; you haven't been nearly persuasive enough to sell that one. I don't even see an argument here for deprecating it, because if you ask me it works better than the SQL-spec behavior. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings