Michael Robinson <robinson@netrinsics.com> writes:
> Is this fixed in later versions? If not, should I send in a patch?
What would you consider a patch? cash_div_flt8 rounds its result,
cash_div_int4 truncates. Which is right, and how many existing
apps might you break by changing the other one? How many of the
other money operators need to be tweaked too?
As Aaron points out, the money data type is looking awfully
dinosaur-like; nothing based on an int4 underlying representation
can possibly be really satisfactory for this purpose. The general
consensus on the hackers list has been that the money type should
be deprecated and eventually phased out. In the meantime, subtle
alterations of its behavior are of dubious value.
It seems to me, though, that the money type does offer a couple of
useful things that you don't get in raw NUMERIC; specifically,
input and output functions that are customized for currency display.
What really would be a useful project would be to reimplement money
as a thin overlay on NUMERIC, basically just input/output functions.
The interesting part of the job would be to do better in non-US
locales than we currently do; I don't think the money code is very
flexible about commas versus decimal points, for example.
regards, tom lane