On 29/03/15 13:07, David G. Johnston wrote:
On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier
<michael.paqu...@gmail.com <mailto:michael.paqu...@gmail.com>>wrote:
On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower
<gavinflo...@archidevsys.co.nz
<mailto:gavinflo...@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.
So, create a numeric type for each possible rounding mode? That
implies at least two types, round-half-even and
round-half-away-from-zero, with suitable abbreviations: numeric_rhe,
numeric_raz.
If the goal is to make plain numeric IEEE standard conforming then
giving the user a way to switch all existing numeric types to
numeric_raz would be nice.
Implicit casts between each of the various numeric types would be
needed and understandable.
I'm pondering calling them numeric_eng and numeric_bus (for
engineering and business respectively)...
David J.
In Java, there are 8 rounding modes specified:
https://docs.oracle.com/javase/8/docs/api/java/math/RoundingMode.html
Some of these may be relevant to pg.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers