From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Integer datetimes |
Date: | 2007-05-16 15:46:11 |
Message-ID: | 200705161546.l4GFkBZ08045@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---------------------------------------------------------------------------
Neil Conway wrote:
> What is the reasoning behind having two different implementations of the
> datetime types, with slightly different behavior? Do we intend to keep
> supporting both FP- and integer-based datetimes indefinitely?
>
> Clearly, there are some costs associated with maintaining two different
> implementations:
>
> (1) It means we need to maintain two sets of code, with a corresponding
> increase in the maintenance burden, the probability of introducing bugs,
> etc., and making datetime behavior more difficult to test.
>
> (2) In general, I think it is a fundamentally *bad* idea to have the
> semantics of a builtin data type differ subtly depending on the value of
> a configure parameter. It makes writing portable applications more
> difficult, and can introduce hard-to-fix bugs.
>
> So, are there any corresponding benefits to providing both FP and
> integer datetimes? AFAIK the following differences in user-visible
> behavior exist:
>
> * integer timestamps have the same precision over their entire range
> (microsecond precision), whereas FP timestamps do not. This is
> clearly an advantage for integer timestamps.
>
> * integer timestamps have a smaller range than FP timestamps
> (294276 AD vs. 5874897 AD). Are there actually applications
> that use timestamps larger than 300,000 AD?
>
> Unless there are lots of applications that need timestamps over such a
> large range, ISTM integer datetimes are the better long-term approach,
> and I don't see how the FP-based datetime code justifies the maintenance
> burden. Notably, the FP datetime code doesn't depend on having a
> functional int64 type, but in 2007, are there really any platforms we
> care about that don't have such a type?
>
> Therefore, I propose that we make integer datetimes the default (perhaps
> for 8.4), and then eventually remove the floating-point datetime code.
>
> Comments?
>
> -Neil
>
> P.S. One thing to verify is that the performance of integer datetimes is
> no worse than the perf. of FP datetimes. I'd intuitively expect this to
> be true, but it would be worth investigating.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2007-05-16 15:52:15 | Re: Not ready for 8.3 |
Previous Message | Jim C. Nasby | 2007-05-16 15:44:10 | Re: Not ready for 8.3 |