Thread: code cleanup of timestamp code

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

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

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

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

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