Re: int64/double for time/timestamp
От | Thomas Hallgren |
---|---|
Тема | Re: int64/double for time/timestamp |
Дата | |
Msg-id | thhal-0AtoQA8PExyc3cTTRuv6pXJu2UUf60M@mailblocks.com обсуждение исходный текст |
Ответ на | Re: int64/double for time/timestamp (Teodor Sigaev <teodor@sigaev.ru>) |
Ответы |
Re: int64/double for time/timestamp
|
Список | 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
В списке pgsql-hackers по дате отправления: