From: Peter Eisentraut on 17 Jul 2010 06:20 On fre, 2010-07-16 at 08:55 -0500, Kevin Grittner wrote: > Peter Eisentraut <peter_e(a)gmx.net> wrote: > > > I didn't see any discussion about why this should return float8 > > rather than numeric. It seems wrong to use float8 for this. > > That discussion took place several months ago on the -bugs list. > I'll paste some links from a quick search of the archives below. > Since multiplication of money is by float8 and not numeric, it > ultimately seemed more consistent to me to have the results of > division be float8. I felt that as long as we had a cast between > money and numeric, someone could always cast to numeric if they > wanted that style of division. > > http://archives.postgresql.org/pgsql-bugs/2010-03/msg00233.php > http://archives.postgresql.org/pgsql-bugs/2010-03/msg00241.php > http://archives.postgresql.org/pgsql-bugs/2010-03/msg00244.php > http://archives.postgresql.org/pgsql-bugs/2010-03/msg00245.php > http://archives.postgresql.org/pgsql-bugs/2010-04/msg00006.php I read most of these messages rather as advocating the use of NUMERIC. Also, the multiplication problem can be addressed by adding a money * numeric operator. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 17 Jul 2010 06:20 On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote: > The other argument that I found convincing was that if the > operator was defined to yield numeric, people might think that > the result was exact ... which of course it won't be, either way. > Choosing float8 helps to remind the user it's an approximate quotient. Why is it approximate? Aren't money values really integers? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andy Balholm on 17 Jul 2010 10:20 On Jul 17, 2010, at 3:20 AM, Peter Eisentraut wrote: > On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote: >> The other argument that I found convincing was that if the >> operator was defined to yield numeric, people might think that >> the result was exact ... which of course it won't be, either way. >> Choosing float8 helps to remind the user it's an approximate quotient. > > Why is it approximate? Aren't money values really integers? $1.00 / 3.00 = 0.333333333333333333333333333333333333333333333333... -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 17 Jul 2010 10:39 Peter Eisentraut <peter_e(a)gmx.net> writes: > On fre, 2010-07-16 at 10:31 -0400, Tom Lane wrote: >> The other argument that I found convincing was that if the >> operator was defined to yield numeric, people might think that >> the result was exact ... which of course it won't be, either way. >> Choosing float8 helps to remind the user it's an approximate quotient. > Why is it approximate? Aren't money values really integers? 1/3 is going to yield an approximate result either way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 17 Jul 2010 11:00
Peter Eisentraut <peter_e(a)gmx.net> wrote: > I read most of these messages rather as advocating the use of > NUMERIC. Yeah, I did advocate that at first, but became convinced float8 was more appropriate. > Also, the multiplication problem can be addressed by adding a > money * numeric operator. True. If we added money * numeric, then it would make more sense to have money / money return numeric. On the other hand, I couldn't come up with enough use cases for that to feel that it justified the performance hit on money / money for typical use cases -- you normally want a ratio for things where float8 is more than sufficient; and you can always cast the arguments to numeric for calculations where the approximate result isn't good enough. Basically, once we agreed to include casts to and from numeric, it seemed to me we had it covered. We're certainly in much better shape to handle exact calculations now that we have the casts than we were before. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |