Re: Rounding to even for numeric data type
От | Michael Paquier |
---|---|
Тема | Re: Rounding to even for numeric data type |
Дата | |
Msg-id | CAB7nPqTLsSg+N0uKHoSB3tRHzzfAvJksVXXeWihMmiMLuOgwLg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rounding to even for numeric data type (Gavin Flower <GavinFlower@archidevsys.co.nz>) |
Ответы |
Re: Rounding to even for numeric data type
Re: Rounding to even for numeric data type |
Список | pgsql-hackers |
On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote: > On 28/03/15 21:58, Dean Rasheed wrote: > [...] >> >> >> Andrew mentioned that there have been complaints from people doing >> calculations with monetary data that we don't implement >> round-to-nearest-even (Banker's) rounding. It's actually the case that >> various different financial calculations demand different specific >> rounding modes, so it wouldn't be enough to simply change the default >> - we would have to provide a choice of modes. > > [...] > > Could the 2 current round functions have cousins that included an extra char > parameter (or string), that indicated the type of rounding? > > So we don't end up with an explosion of rounding functions, yet could cope > with a limited set of additional rounding modes initially, and possibly > others in the future. Instead of extending round, isn't what we are looking at here a new data type? I have doubts that we only want to have a way to switch round() between different modes. Hence, what we could do is: 1) Mention in the docs that numeric does round-half-away-from-zero 2) Add regression tests for numeric(n,m) and round(numeric) 3) Add a TODO item for something like numeric2, doing rounding-at-even (this could be an extension as well), but with the number of duplication that it may have with numeric, an in-core type would make sense, to facilitate things exposing some of structures key structures would help. Regards, -- Michael
В списке pgsql-hackers по дате отправления: