Re: Money type

"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