"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> Also somewhat NA centric is the two decimal places. This was originally
> meant to be locale driven but that is a problem for other reasons. What
> about defaulting it to two decimal places but allowing it to be redefined at
> table creation time? How hard would it be to make it accept an optional
> precision?
Possible, but in 32 bits you don't really have room to offer more
precision. Another objection is that (AFAIK) there's no way to handle
precision specs without wiring them into quite a number of places in the
parser, format_type, etc. I'd object to doing that for a nonstandard
type like money.
> Limited precision. This can be fixed by going to a 64 bit integer for the
> underlying type. Are we at a point where we can do that yet? I am afraid
> that there are still systems that don't have a native 64 bit type.
You could possibly use the same sort of hacks as are in the int8 support
--- type int8 is still functional on int64-less platforms, it just has
the same range as int4. I guess this would be no loss of functionality
compared to where money is now.
> As the original author of the type I naturally have some bias but I still
> think that it is a good type for all the reasons we thought it was a good
> idea before. There is a definite advantage to being able to do integer
> arithmetic right on the CPU in large financial applications.
I'd rather see the effort invested in making type 'numeric' faster.
Even with a 64-bit width, money would still be subject to silent
overflow, which I find uncool for financial applications...
regards, tom lane
