Re: Integer datetimes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Integer datetimes
Date
Msg-id 200705161525.l4GFP1X04246@momjian.us
Whole thread Raw
In response to Integer datetimes  (Neil Conway <neilc@samurai.com>)
Responses Re: Integer datetimes
List pgsql-hackers
Are we agreed to wait for 8.4 for this?

---------------------------------------------------------------------------

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@postgresql.org so that your
>        message can get through to the mailing list cleanly

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Managing the community information stream
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Not ready for 8.3