Michael Paquier michael.paqu...@gmail.com writes:
On Sat, May 2, 2015 at 9:53 PM, Fabien COELHO wrote:
Quick review: patches applies, make check is fine, all is well.
Thanks for the feedback, Fabien!
All the casting tests could be put in numeric.sql, as there are all
related to numeric and
v2 applied tested.
[...] Not sure about that, the tests are placed here to be consistent
with for is done for float8.
Maybe float8 to numeric casts could have been in numeric too.
[...] I reworked the example in the docs.
Indeed, looks good.
--
Fabien.
--
Sent via pgsql-hackers
On Sat, May 2, 2015 at 9:53 PM, Fabien COELHO wrote:
Quick review: patches applies, make check is fine, all is well.
Thanks for the feedback, Fabien!
All the casting tests could be put in numeric.sql, as there are all
related to numeric and that would avoid duplicating the values lists.
Not
So, attached is a patch that does 1) and 2) to make clear to the user
how numeric and double precision behave regarding rounding. I am
adding it to CF 2015-06 to keep track of it...
Quick review: patches applies, make check is fine, all is well.
Two minor suggestions:
All the casting tests
On Wed, Apr 22, 2015 at 9:30 PM, Pedro Gimeno
pgsql-...@personal.formauri.es wrote:
Dean Rasheed wrote, On 2015-03-28 10:01:
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards
Dean Rasheed wrote, On 2015-03-28 10:01:
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards compatibility here is probably
Tom overblown; but if we're sufficiently worried about it, a
Michael Paquier wrote:
Well, I am not sure about that... But reading this thread changing the
default rounding sounds unwelcome. So it may be better to just put in
words the rounding method used now in the docs, with perhaps a mention
that this is not completely in-line with the SQL spec if
On Mon, Mar 30, 2015 at 4:51 AM, James Cloos cl...@jhcloos.com wrote:
MP == Michael Paquier michael.paqu...@gmail.com writes:
MP So, attached is a patch that does 1) and 2) to make clear to the
MP user how numeric and double precision behave regarding rounding.
MP I am adding it to CF 2015-06
On Sun, Mar 29, 2015 at 9:21 AM, Gavin Flower
gavinflo...@archidevsys.co.nz wrote:
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.comwrote:
On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower
On Sun, Mar 29, 2015 at 7:59 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
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
MP == Michael Paquier michael.paqu...@gmail.com writes:
MP So, attached is a patch that does 1) and 2) to make clear to the
MP user how numeric and double precision behave regarding rounding.
MP I am adding it to CF 2015-06 to keep track of it...
Given that the examples show -2.5 rounds to -3,
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)
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
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.comwrote:
On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower
gavinflo...@archidevsys.co.nz
mailto:gavinflo...@archidevsys.co.nz wrote:
On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
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
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
Dean Rasheed dean.a.rash...@gmail.com wrote:
Sure, using round-to-nearest-even for intermediate rounding in
complex numeric methods would be a good way to reduce (but not
completely eliminate) rounding errors. But that's a somewhat
different proposition from changing the default for round(),
On 27 March 2015 at 23:26, Tom Lane t...@sss.pgh.pa.us wrote:
Michael Paquier michael.paqu...@gmail.com writes:
It sounds appealing to switch the default behavior to something that
is more IEEE-compliant, and not only for scale == 0. Now one can argue
as well that changing the default is risky
On 28 March 2015 at 05:16, Andrew Gierth and...@tao11.riddles.org.uk wrote:
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards compatibility here is probably
Tom overblown; but if we're sufficiently worried about it, a possible
Tom compromise is to invent a
Hi all,
A couple of days ago a bug has showed up regarding rounding of float here:
http://www.postgresql.org/message-id/flat/20150320194337.2573.72...@wrigleys.postgresql.org#20150320194337.2573.72...@wrigleys.postgresql.org
The result being that the version of rint() shipped in src/port was
not
Michael Paquier michael.paqu...@gmail.com writes:
It sounds appealing to switch the default behavior to something that
is more IEEE-compliant, and not only for scale == 0. Now one can argue
as well that changing the default is risky for existing applications,
or the other way around that other
Tom == Tom Lane t...@sss.pgh.pa.us writes:
Tom I think the concern over backwards compatibility here is probably
Tom overblown; but if we're sufficiently worried about it, a possible
Tom compromise is to invent a numeric_rounding_mode GUC, so that
Tom people could get back the old behavior
22 matches
Mail list logo
