Re: Re: BUG #12885: The result of casting a double to an integer depends on the database version - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: Re: BUG #12885: The result of casting a double to an integer depends on the database version
Date
Msg-id CAB7nPqTSwzAWGpueQwhm9R0zO8gb_eA6NZm15_=NJDQfN_i00g@mail.gmail.com
Whole thread Raw
In response to Re: Re: BUG #12885: The result of casting a double to an integer depends on the database version  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-bugs
On Sat, Mar 28, 2015 at 2:16 AM, Dean Rasheed wrote:
> On 27 March 2015 at 12:32, Michael Paquier wrote:
>> Attached is a patch that adds nearest-to-even rounding for numeric
>> when dscale = 0.
>
> I'm not convinced that it is a good idea to change the default
> rounding mode for numeric.
>
> For one thing, numeric is commonly used for monetary data, and
> changing the default rounding mode might well break existing
> applications where rounding is important, and which rely on the
> current behaviour. Granted the current rounding mode doesn't appear to
> be documented anywhere (which it probably should be), but still, it
> seems like a risky thing to change.

It is possible to argue the other way around here. For people
migrating to Postgres, perhaps the behavior that we have is surprising
as well. Perhaps other RDBMS behave using rounding-to-even.

> I'd also argue that the current "round half away from zero" mode is
> the most widely known rounding mode, since it is commonly taught at
> school, so it seems like the more sensible default.
>
> ISTM that there would have to be a good reason to change the default,
> and compatibility with IEEE floats doesn't seem very convincing to me.
> I would never assume numerics are meant to have anything in common
> with IEEE floats.
>
> Adding a version of round() with support for a choice of various
> rounding modes might be a better way to go.

Each argument has its strengths. Consistency with float and rint() is
appealing as well...

> Also, if the default is being changed, I think that merits wider
> discussion (on a thread with a more appropriate title) to see if it is
> likely to be an issue for anyone.

Yeah, that makes sense. I'll raise one on -hackers.
--
Michael

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Re: BUG #12885: The result of casting a double to an integer depends on the database version
Next
From: Jeff Davis
Date:
Subject: Re: pg_get_constraintdef() doesn't always give an equal constraint