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
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
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
Neil Conway [EMAIL PROTECTED] 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
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
