Michael,
> I've completed my first cut of adding a day field to the interval
> struct and patched up the regression tests for places where it failed
> due to the new behavior (e.g., interval '19:00' + interval '6:00' =
> interval '25:00'). I haven't added any regression tests for the DST
> behavior, but it works (and this could be the start of the regression
> tests). Note: DST changed on 2005-04-03:
This looks good so far. I could have really used this for 2 calendar
applicaitons, and *will* use it for my next one. This is exactly the kind of
behavior that calendar applications need.
> One interesting fallout of this is that adding two SQL-compliant
> intervals can produce non-SQL-compliant output:
>
> test=# select interval '3 days 16:39' + interval '1 day 15:32' as
> "interesting";
> interesting
> -----------------
> 4 days 32:11:00
I personally don't have a problem with this if the my/dw/hms split is fully
documented. Does it put is in violation of the SQL spec, though? If so, do
we care?
Anyone know how Oracle/DB2 handles this? ( I know how MSSQL handles it --
badly.)
> I've added a interval_simplify function which assumes 1 day = 24
> hours and puts the interval in SQL-spec form. This could be exposed
> to let people "reduce" their intervals. However, I'm concerned this
> is surprising behavior.
Yes, well, we'll have to document it prominently in the release notes and
elsewhere.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
