Thread

1. code cleanup of timestamp code

   Warren Turkal <turkal@google.com> — 2008-02-26T08:22:03Z

   I am working on some beginner level patches to help clean up the
   timestamp code in PostgreSQL.
   
   Basically, my first few patches are aimed at removing the dependence
   on the HAVE_INT_TIMESTAMP to choose types for variables. I will
   eventually try to remove the use of HAVE_INT64_TIMESTAMP to choose
   procedural code as well. I think that it will make the code easier to
   read.
   
   As a result, I have a few questions about the timestamp code. In what
   instances is the floating point timestamp recommended? I see that
   Debian and Ubuntu ship packages that use the int64 timestamps. Is the
   backend smart enough to not load and use a database with timestamp
   fields created with the representation not compiled into the compiler?
   And finally, would this work be welcome in PostgreSQL? I view is as a
   kind of beginner janitor type of project to get my feet wet.
   
   Thanks,
   wt
   
   

2. Re: code cleanup of timestamp code

   Martijn van Oosterhout <kleptog@svana.org> — 2008-02-26T09:37:07Z

   On Tue, Feb 26, 2008 at 12:22:03AM -0800, Warren Turkal wrote:
   > As a result, I have a few questions about the timestamp code. In what
   > instances is the floating point timestamp recommended? I see that
   > Debian and Ubuntu ship packages that use the int64 timestamps. Is the
   > backend smart enough to not load and use a database with timestamp
   > fields created with the representation not compiled into the compiler?
   > And finally, would this work be welcome in PostgreSQL? I view is as a
   > kind of beginner janitor type of project to get my feet wet.
   
   AIUI it's because there are systems that have broken 64-integer
   support. Or at least, that's the theory. There was a question recently
   to check if there really are such systems still running...
   
   Have a nice day,
   -- 
   Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
   > Those who make peaceful revolution impossible will make violent revolution inevitable.
   >  -- John F Kennedy
   

3. Re: code cleanup of timestamp code

   Neil Conway <neilc@samurai.com> — 2008-02-26T18:54:02Z

   On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
   > As a result, I have a few questions about the timestamp code. In what
   > instances is the floating point timestamp recommended?
   
   One circumstance is when there isn't a native int64 type available. The
   floating point datetime code is the traditional implementation -- until
   recently the integer datetime code was less tested and more buggy,
   although I don't think that is still the case. For 8.4 I'm planning to
   submit a patch to make integer datetimes the default, per earlier
   discussion.
   
   > Is the backend smart enough to not load and use a database with
   > timestamp fields created with the representation not compiled into the
   > compiler?
   
   Postgres will refuse to start if the compiled-in datetime representation
   doesn't match the datetime representation used by the specified data
   directory.
   
   > And finally, would this work be welcome in PostgreSQL?
   
   Yes, sounds like a useful improvement to me. There are quite a few
   cleanups and refactorings that could be done to the datetime code.
   
   -Neil
   
   
   
   

4. Re: code cleanup of timestamp code

   Tom Lane <tgl@sss.pgh.pa.us> — 2008-02-26T19:55:34Z

   Neil Conway <neilc@samurai.com> writes:
   > On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
   >> As a result, I have a few questions about the timestamp code. In what
   >> instances is the floating point timestamp recommended?
   
   > One circumstance is when there isn't a native int64 type available.
   
   There are other possible reasons to prefer the float implementation;
   for example it has wider range than the int64 code.  Most people have
   no need to represent dates beyond 6 million AD, of course, but I think
   it's at least potentially useful for some scientific applications.
   
   Also, despite the Niagara-centric moans you may have noticed from some
   Sun hackers, float arithmetic is faster than int64 on quite a wide
   variety of recent hardware.  That may sound counterintuitive but float
   units have been a traditional place to fling any surplus of gates at,
   while if you don't have 64-bit hardware then int64 isn't really a native
   type.  MegaFLOP ratings are marketable, mega-int64-ops not so much.
   (Though it's possibly true that the actual arithmetic in datetime.c is
   buried under too much logic for it to make a noticeable difference :-()
   
   Anyway I think they both have their place.  int64 is a sensible default,
   because it doesn't have the type of non-decimal behavior that tends
   to surprise novices (compare today's bug #3991).  But I don't see float
   disappearing entirely.
   
   			regards, tom lane
   
   

5. Re: code cleanup of timestamp code

   Neil Conway <neilc@samurai.com> — 2008-02-26T20:06:39Z

   On Tue, 2008-02-26 at 14:55 -0500, Tom Lane wrote:
   > Anyway I think they both have their place.
   
   I think it is very fragile to have the semantics of a builtin datatype
   change depending on a configure option. It makes it difficult to write
   applications that depend on the unique properties of *either* of the
   implementations, and introduces the possibility of subtle portability
   issues (e.g. your application works fine when developed against a build
   of Postgres with integer datetimes, but subtly loses precision when used
   with a floating-point build). It also complicates life for binary-mode
   clients.
   
   If we're convinced that both implementations are worth keeping, IMHO the
   better route would be to separate them into two distinct sets of
   datatypes. If not that, then I'd like to see integer datetimes adopted
   as the default, and FP datetimes deprecated.
   
   -Neil