On 2000-01-18, Thomas Lockhart mentioned:
> > We are going to internally move everything to the more standard ANSI
> > names, right, or do we give preference to the older types?
>
> Well, that could be up for discussion. The "internal" abstime/reltime
We might as well make that change now rather than dragging the old baggage
(8 different types after all!) around for another major release. I don't
mean dropping them but putting forth a clear preference.
Preferred set: timestamp, interval, date, time
timespan: alias to interval, for compatibility
datetime: alias to timestamp, for compatibility
abstime, reltime: deprecated, used only for internal catalogs
I mean that would make sense to me as a user. I have long been confused
about that.
> types are direct copies of Unix system time, which most systems
> support at a fundamental level. Moving to timestamp/interval will
The problem also seems to be that on some systems they seem to be 8 byte
types (see original TODO item). So either you move it to proper int32
types, thus losing the exact correspondence, or you make them aliases to
timespan and interval as well and lose them sometime.
> double the storage size of those fields, with no increase in
> functionality afaik.
Isn't storage size in multiples of 8192 anyway? So this probably makes
zero difference in practice.
> Peter brought up changing one field to timestamp; that would have the
> benefit of being able to specify times past y2038.
The Y2038 problem is next. We could be the first ones to comply. :)
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden