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
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 |