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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
Cc: Postgres Hackers List <hackers(at)postgresql(dot)org>
Subject: Date/time types (Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog (pg_type.h))
Date: 2000-01-19 02:58:29
Message-ID: Pine.LNX.4.21.0001190047490.11420-100000@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-01-19 02:58:37 Re: [HACKERS] pg_proc.h changed
Previous Message Bruce Momjian 2000-01-19 02:45:27 Re: [HACKERS] Index recreation in vacuum