Re: int64/double for time/timestamp

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: int64/double for time/timestamp
Date: 2005-02-22 18:44:23
Message-ID: 11246.1109097863@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> It looks consistently, but for time (from utils/date.h):

> ifdef HAVE_INT64_TIMESTAMP
> typedef int64 TimeADT;
> #else
> typedef float8 TimeADT;
> #endif

> #define TimeADTGetDatum(X) Float8GetDatum(X)
> #define DatumGetTimeADT(X) ((TimeADT) DatumGetFloat8(X))

> So, in case HAVE_INT64_TIMESTAMP int64 may use as float8. Is it correct?

Urgh. This is clearly a bug. All the code in utils/adt seems to be
correctly set up to treat TimeADT as an integral value, but then the two
macros quoted are converting the value to float8 and back again ... so
what's actually on disk is the float8 equivalent of what the int64 value
is supposed to be :-(. As long as the macros are used *consistently* to
fetch and store time datums, no one would notice --- you could only see
a difference if the int64 values got large enough to not be represented
completely accurately as floats, which I believe is impossible for type
time.

So the fact that you're seeing a bug in btree_gist suggests that
someplace you're cheating and bypassing the FooGetDatum/DatumGetFoo
macros.

We'll obviously want to fix this going forward for efficiency reasons,
but it's an initdb-forcer because it'll change the on-disk
representation of time columns. So we can't change it in 8.0 or before.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kurt Roeckx 2005-02-22 18:57:15 Re: [PATCHES] [pgsql-hackers-win32] Repleacement for src/port/snprintf.c
Previous Message Andreas Pflug 2005-02-22 18:42:59 Re: Get rid of system attributes in pg_attribute?