"Brendan Jurd" <direvus@gmail.com> 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
