Re: [HACKERS] Sum aggregate calculation for single precsion real

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [HACKERS] Sum aggregate calculation for single precsion real
Дата
Msg-id CAM-w4HM0GkCN5PgyYgLbFHXj8JEV8=T8AN7bYUiu_grYPF4zjQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Sum aggregate calculation for single precsion real  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Sum aggregate calculation for single precsion real  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 15 February 2017 at 12:52, Robert Haas <robertmhaas@gmail.com> wrote:
> Personally, I find it somewhere in the middle: I think the way it
> works now is reasonable, and I think what he wants would have been
> reasonable as well.  However, I find it hard to believe it would be
> worth changing now on backward compatibility grounds.

Honestly I was quite surprised to discover that sum(float4) worked
this way because I assumed it followed the same pattern as integers.

But I wonder what you mean by backward compatibility grounds. If
sum(float4) returned a float8 the only compatibility issue would be
someone who did "create table as" and then expected to get a float4
column and instead got a float8 column. That seems like a much more
minor corner case than most any other backward incompatible change in
any release.

Moreover, it wouldn't be hard to make sum(float4) use a float8 as an
accumulator and then cast to float4 for the final state. That would be
100% compatible with the existing behaviour aside from producing more
accurate results.

(Though as an aside, I think Konstantin would be much better served by
using integers and storing cents or whatever unit of currency is small
enough. That would actually result in accurate results which neither
float4 nor float8 guarantee.)

-- 
greg



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Gather Merge
Следующее
От: Rushabh Lathia
Дата:
Сообщение: Re: [HACKERS] Gather Merge