On Sat, Mar 28, 2015 at 5:58 PM, Dean Rasheed wrote:
> On 27 March 2015 at 23:26, Tom Lane wrote:
>> I think the concern over backwards compatibility here is probably
>> overblown; but if we're sufficiently worried about it, a possible
>> compromise is to invent a numeric_rounding_mode GUC, so that people
>> could get back the old behavior if they really care.
>>
>
> Backwards compatibility is certainly one concern. Michael also
> mentioned compatibility with other databases, and its worth noting
> that Oracle, MySQL, DB2 and SQL Server all use the same default
> round-half-away-from-zero "Schoolbook" rounding mode in round() for
> their equivalents of numeric. Most of those other DBs are also careful
> to document exactly how round() behaves. To make our round() function
> do something different by default isn't going to make porting any
> easier.
I was not aware of that, and that's really an interesting point.
Thanks! It would indeed not be welcome for people migrating an
application to Postgres if we behave differently from the others.
Then, perhaps the solution would be to have this rounding GUC, but
pointing by default to round-half-away-from-zero and not round-to-even
as mentioned upthread already.
> 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. I also agree with Andrew
> that all numeric functions should be kept immutable.
This looks like a plan. Honestly by reading this thread the thing that
IMO we should not do is closing ourselves into a single mode of
calculation.
--
Michael