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

Reply via email to