From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
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-03-14 07:47:11 |
Message-ID: | thhal-0AtoQA8PExyc3cTTRuv6pXJu2UUf60M@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Teodor Sigaev wrote:
>> 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.
>
>
> So, will we do it? I can do, but I don't know: Is there a place which
> contains storage version (except file PG_VERSION)?
>
>
When making PL/Java dynamically adapt to the setting of
integer-datetimes, I too was bitten by this bug. Is it safe to assume
that the fix for this will arrive in 8.1.0?
Regards,
Thomas Hallgren
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-03-14 07:53:36 | Re: invalidating cached plans |
Previous Message | Neil Conway | 2005-03-14 07:36:17 | Re: invalidating cached plans |