From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Postgres Hackers List <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Date/time types: big change |
Date: | 2000-02-17 06:04:45 |
Message-ID: | 38AB8F7D.F164A256@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I've just committed changes to "reunify" the date/time types.
> > "timestamp" and "interval" are now the two primary date/time types for
> > users. Also, I've changed the default date style to "ISO" (not just in
> > time for Y2K, but we'll be ready for "Y3K").
> I still don't like our Y2038 status. ;)
Yeah. Like the ntp rfc doc says: "we'll expect the solution to appear
before it is needed" or something to that effect.
> Anyway, the question I have is what did you do with functions such as
> datetimein() or comparison functions and such for the old types? Did you
> remove them? What if some, say, user-defined trigger function uses them?
Then they are SOL. I had originally implemented datetime and timespan
as an experiment to see if a floating point number could behave well
enough to represent dates (I was worried about rounding and the
.999999 problem, especially with the wide range of platforms we
support).
So it turns out that they work. In the meantime, someone contributed a
timestamp type, but did not fully implement it and chose a 4 byte
representation, which is fundamentally flawed imho.
I've been waiting a year or two to do this upgrade, and the major rev
bump is the time and place to do it.
One reason why I didn't carry along both datetime *and* timestamp is
the large number of related functions and operators. It would have
significantly increased the size of the catalogs (mostly because
timestamp didn't have much to start with).
> The reason I'm asking is that I would like to see the floating point types
> converted to SQL in a similar fashion, but when I rename, say, float4eq to
> realeq it might break user applications. Or not? This is all hypothetical
> of course.
Lots of work for not much gain imho. For the date/time stuff, it made
sense because timestamp needed to be replaced. There isn't the same
underlying need for the floating point types afaik.
On the other hand, 7.0 (or 8.0, but that may be another 4 years ;) is
the time to do it. Does anyone else see this as an issue?
- Thomas
--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-02-17 06:12:14 | Re: [HACKERS] Date/time types: big changeu |
Previous Message | Hiroshi Inoue | 2000-02-17 06:04:03 | RE: [HACKERS] create database doesn't work well in MULTIBYTE mode |