On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower <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. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
