This has been saved for the 8.4 release:


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 [EMAIL PROTECTED] so that your
>        message can get through to the mailing list cleanly

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to