From: Peter Eisentraut on
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
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
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
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
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