On Tue, Mar 30, 2010 at 12:22 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> [Did you mean to take this off-list, or was that accidental?]
Accidental.
>
> Chris Travers <chris@metatrontech.com> wrote:
>
>> With due respect, this sort of thing is rather difficult to get
>> right all at once.
>
> Division of two fixed-point numbers we already know how to add, or
> the whole suite of all features one might possibly want in a
> monetary data type? =A0(I get the feeling that some of the posts on
> this thread involve a straw man going down a slippery slope.... ;-)
Ok. Here is my application: I write a multi-currency accounting
program backed by PostgreSQL. After 1.3 is released (2Q this year),
we expect to be doing a full redesign.
What I am thinking about is having a custom data type, something like:
CREATE DOMAIN curr VARCHAR(3);
CREATE TYPE monetary AS (amount NUMERIC, currency CURR, multiplier
NUMERIC); This reduces into two basic components: a value (amount *
multiplier) and a currency identifier (USD, etc).
One could also then store monetary[] arrays for addressing specific
denomination storage. I.e. "When closing the till we had 26 pennies,
53 nickles, 12 quarters, 25 $1 bills, 35 $5 bills, 15 $10 bills, and 5
$20 bills."
Then we can allow NUMERIC arithmetic on monetary amounts provided that
the CURR field is the same. We could also store things like the cash
counted from a till at the end of the day by denomination. One could
have easy monetary::numeric casts as well.
Anyway, that's my basic thinking. One could further add currency
conversion tables to an application if necessary.
Just thinking about the more general problem and how things could be
handled more gracefully...
Best Wishes,
Chris Travers