Re: age() function documentation

Thomas Lockhart writes:

> > b) date substraction not implemented at all (it does date - integer)
>
> No, and changing what it *does* do has ramifications.

Okay, I see there's 'date - date' after all. But 'date - date' should
still return some kind of time interval, not an integer. Of course
changes have ramification, but standing still does, too.

> > d) intervals not implemented per spec
>
> ? Why would you say this?

Because it's a fact. SQL has year to month intervals and day to second
intervals, no all encompassing interval. It sounds stupid at first, but a
lot of weird little definitional problems would go away if we had support
for these. Months and years are "unstable" units when used together with
days, minutes, etc. but they are a consistent system when only used among
themselves. The current implementation already reflects this by making
"time" and "month" different struct members, so I guess what lacks a
little are user-accessible means of controlling which gets used.

The difference is between age() and timestamp subtraction is in fact that
the former returns a year to month interval and the other a day to second
interval. But in the current implementation the only effective difference
is that the interval is diplayed differently, which is a confusing concept
because data values are not defined by their representation but by their
value.

> Please be specific about what you think needs changing, and why. And
> I'll actually be able to pay attention after the 7.1 release ;)

Fix^H^H^HEnhancing the interval type up to spec would really go a long way
I think. We could redefine Interval like

struct Interval {
bool is_month_to_year;
union {
double seconds;
struct my {
int32 months;
int32 years;
}
}
}

This would make it mostly compatible to its current behaviour.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/