Re: code cleanup of timestamp code

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Warren Turkal <turkal(at)google(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: code cleanup of timestamp code
Date: 2008-02-26 20:06:39
Message-ID: 1204056399.29147.23.camel@dell.linuxdev.us.dell.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-02-26 20:14:49 Re: pg_dump additional options for performance
Previous Message Tom Lane 2008-02-26 20:03:47 Re: pg_dump additional options for performance