Re: Proposal for 2.0: New monetary data types

["Adam Thompson" <..hidden..>]

> Also all math within the function should be integer math, and the
> return
> result should be left as full precision real.
> This will avoid all rounding error.
> The result can then be rounded at application level.

It's impossible (AFAIK) to avoid all rounding errors in monetary amounts 
as long as there continue to exist - anywhere in the world - irrational 
denominations.

I can't name any such systems *currently* in use, although the most 
obvious example is the Commonwealth (British) Shilling and Pence, set at 
1s=12d.  (Abbr for pence is d, not p.)  If you want a fully generalizable 
monetary currency system, you probably also have to accommodate such 
bizzarities as the conversion between shillings and sheep :-)  (1 shilling 
= 1 sheep in Anglo-Saxon era, FYI... who needs a gold standard?!)  FWIW, 
the old French sou was worth 12 deniers (origin of "d" as abbreviation).

Not to mention the guinea, fixed at 21 shillings, where 20 shillings = 1 
pound sterling, which makes 1 guinea = 1 1/21 pounds. If you want to 
support arbitrary conversions, 44 1/2 guineas = 1 troy ounce of gold.  Or 
the Dutch stuiver, at 16 penning, although at least that's a rational 
fraction.

If you want to retain rational mathematics, never mind integer math, 
you'll pretty much have to declare that the type explicitly supports only 
currencies in use from 1971-Feb-15 onward, although that's probably better 
phrased as:
	* You should probably limit the type to decimalized currencies, and state 
that limitation explicitly.

Aside from historical curiosities, the more I read of this proposal, the 
more I smell feeping creaturism... increasingly, it doesn't sound like 
something that can reasonably be black-boxed into a custom data type; 
arbitrary monetary declaration, registration, etc., is an entire 
application's worth of data, or at least a major subsystem.  I would 
compare this to the TZ subsystem in unix-like OSes: the complexity quickly 
becomes insane once you start capturing temporal data.  As an example, 
what do you do with currencies that have been rebased or devalued, yet 
retain their ISO currency code?  The only solution I can see is to also 
require an "effective date" as part of the type definition.  If I want to 
compare two pieces of data denominated in the *same* currency (ignoring my 
previous case), since we have to store historical data (at least about 
exchange rates, anyway) does the comparison take into account the 
difference in a single currency's valuation?

For that matter, if it's encapsulated as a Pg custom type, how/where does 
one store exchange rate data?  (I don't know an awful lot about custom 
data types in Pg, this might be a simple answer...)

This isn't an impossible task (again, witness the TZ subsystem), but what 
we think of as historical curiosities today might well turn into reality 
tomorrow - I'm not about to try predicting what government or regime X in 
country Y might decide to do with its currency.  Who gets to maintain all 
that data?  Some quasi-centralized maintenance group?  Every user?

It sounds like a decent idea, but I would be more comfortable if this 
remained encapsulated inside applications that need it, or if this became 
some sort of standardized library (again, like TZ data) rather than a data 
type specific to one database.

(Oh, if anyone cares, the various (historically recent) British coinages 
are listed at 
http://en.wikipedia.org/wiki/Coins_of_the_pound_sterling#Pre-decimal_coinage.)

-Adam Thompson
 <..hidden..>
 (204) 291-7950