Re: int64/double for time/timestamp

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: int64/double for time/timestamp
Дата
Msg-id 421F4357.1080604@sigaev.ru
обсуждение исходный текст
Ответ на Re: int64/double for time/timestamp  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: int64/double for time/timestamp  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: int64/double for time/timestamp  (Thomas Hallgren <thhal@mailblocks.com>)
Список pgsql-hackers
> 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)?


-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Where are we on stored procedures?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: UTF8 or Unicode