Re: Date/time types (Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog(pg_type.h))

> 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.

Hmm. I *think* I state a clear preference in the User's Guide. Is
there another place to mention this? Should we be more explicit?? If
we're going to fix it up, we need some suggestions ;)

> 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.

That's a detail on 64 bit systems like Alpha/Unix, but afaik one can
force the field into 4 bytes and you get the Right Thing, at least
until 2038. I'd prefer moving to an 8 byte integer, but we don't have
those on enough of our supported platforms, so the 8 byte float is the
next best thing to get past 2038.

> > 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.

It actually makes a big difference on the simplest tests, which have a
single small column. Then, the tuple overhead is most obvious, and
(I'm not sure of the actual numbers) going from 40 bytes to 60 bytes
is significant.

> > 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. :)

Since we are currently mapping to Unix system time, I'd rather go slow
and wait for a good OS solution. Or we could go to 8 byte integers
with 100ns ticks a la Corba Time (hmm, maybe we can get an
implementation from somewhere which would work on all of our
platforms??). The double we currently have for user time isn't likely
to be what OSes end up using, though with our license they could ;)

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California