Re: Money type todos?

Tom Lane wrote:
> Dennis Bjorklund <db@zigo.dhs.org> writes:
>> Tom Lane skrev:
>>> Whether it is actually ever going to disappear is not agreed upon.
> 
>> What is the reason to keep it?
> 
> The words-of-one-syllable answer is that D'Arcy Cain is still willing
> to put work into supporting the money type, and if it still gets the
> job done for him then it probably gets the job done for some other
> people too.
> 
> Personally, as a former currency trader I've not seen any proposals on
> this list for a "money" type that I'd consider 100% feature complete.
> The unit-identification part of it is interesting, but pales into
> insignificance compared to the problem that the unit values vary
> constantly; what's more, that variance is not to be swept under the rug
> but is exactly the data that you are interested in.  Next, the units
> themselves change from time to time (euro? what's that?); next, the
> interconversion rates aren't all exactly equivalent, and that's not
> noise either but rather very interesting data (see "arbitrage").
> 
> So I'm not feeling inclined to try to prescribe that datatype X is
> good while datatype Y is bad.  It's more about whether there's an
> audience for any particular datatype definition.  The present money
> code gets the job done for D'Arcy and probably some other people,
> and we see some straightforward ways to improve it to serve some
> more cases, so what's wrong with pursuing that path?
> 
>             regards, tom lane

Agreed with Tom on this one. Full usage of money is beyond tagged types
etc. For example, when you earn money in another currency, it is the
time at which you earn it that describes its value. So for P&L accounts
there is generally no change in exchange rates over time and you need to
track what the rate was at time of earning. Solution is to date earnings
and have a table of exchange rates by day.

For balance sheet accounts, their value at a given point in time in a
home currency is of course dependent on exchange rates which creates the
currency gain or loss on the P&L side, the account that captures
exchange rate movements. But this is dependent on the relative
differences between the rates when every dollar was earned and current
rates.

Darcy had suggested removing the currency symbol. That is a change I'd
support. The only other nice thing would be user defined precision, but
can live without that as most currencies work under nnn.mm. Speed is
everything in these systems. For a complex general system you often can
get away with integers if you define at the app layer the handling
(including a lookup in system for format, type).

- August