Money type

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's better than
use dagerous float and hard coded currency symbol.

For example in my country (and a lot of others) is the current money
datetype total useless. We have currency symbol after number, 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