Thread: Money type

I know that the money type is supposed to be deprecated but I think that 
there is still some benefit to it.  It is small and fast.  There are some 
problems and I would like to address them.

The output has a dollar sign attached.  This is NA centric and we said years 
ago that we were going to drop it.  I think that that is enough warning.  
Unless someone has a problem with that I will just go in and get rid of it.

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?

It doesn't cast to other types.  If it simply cast to float that would allow 
it to be more flexible.  Do I need to add a float return function for that to 
work?

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.  This is 
not as critical as the other items I think.

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.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thu, May 16, 2002 at 06:11:43AM -0400, D'Arcy J.M. Cain wrote:
> I know that the money type is supposed to be deprecated but I think that 
Right.

> there is still some benefit to it.  It is small and fast.  There are some 
> problems and I would like to address them.
> 
> The output has a dollar sign attached.  This is NA centric and we said years 
> ago that we were going to drop it.  I think that that is enough warning.  
> Unless someone has a problem with that I will just go in and get rid of it.
> 
> 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?
>
> It doesn't cast to other types.  If it simply cast to float that would allow 
> it to be more flexible.  Do I need to add a float return function for that to 
> work?
> 
> 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.  This is 
> not as critical as the other items I think.
I think right is use numeric and to_char() for currency symbol and common and locales correct number formatting. IMHO
it'sbetter thanuse dagerous float and hard coded currency symbol.
 
For example in my country (and a lot of others) is the current moneydatetype total useless. We have currency symbol
afternumber, etc.
 
Sorry but _IMHO_ is better a less good supported types than more bad datetypes.
       Karel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz

"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