Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2

Поиск
Список
Период
Сортировка
От
Тема Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
Дата
Msg-id Pine.LNX.4.10.10008061619560.24207-100000@nemo.house
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: Trouble with float4 afterupgrading from 6.5.3 to 7.0.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
> > Is there a reason we can't perform the conversion and then copy the
> > low-order bits manually, with some bit-shifting and masking?
>
> *What* low-order bits?  The fundamental problem is we don't have 'em.

OK, we represent 10.1 (decimal) with 1010.000110011..., repeating the 0011
pattern. In floating point representation, we say this is 2^3 *
1.010000110011..., repeating the 0011 pattern.

But this dosen't work very well, because when we print it out it won't be
exact, it will be some decimal number ending in a 0 or a 5. So when we
read this out in decimal, we get 10.099999995, with a variable number of
9's depending on the precision we use.

When we print this number out, we perform the decimal conversion, and then
truncate the last decimal digit and round.

So I guess the question is, why can't we perform 4-bit float -> 8-bit
float conversion via a decimal conversion, irrespective of storing the
thing in ASCII.

Mabye the decimal conversion is too costly? Perhaps we could 1) mark 4-bit
floats with a flag of some kind indicating whether or not the decimal
conversion is necessary, and 2) avoid this conversion wherever possible,
including giving people a warning when they use float4s in their tuples.

Or mabye I'm just being dumb.

Ian




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

Предыдущее
От:
Дата:
Сообщение: Re: foreign keys
Следующее
От: Mike Mascari
Дата:
Сообщение: Re: pg_dump help