Consider changing the way postgres composite types are stored

[doughsay]

I'd like to know what the motivation behind storing the numeric amount in postgres composite types as a numeric(20,8) is. With this setup, storing "USD 10.00" for example, turns into "USD 10.00000000" in the db, and then when retrieving it, it retains the precision.

I wanted more control over how much precision is stored for certain columns. I changed the composite money type from what the readme mentions:

CREATE TYPE public.money_with_currency AS (currency_code char(3), amount numeric(20,8))

To this:

CREATE TYPE public.money_with_currency_new AS (currency char(3), amount numeric)

It works much better for my use cases. Is there any reason why this shouldn't be the default?

[kipcole9]

@doughsay, its a very reasonable question. My original design decision was based upon discussions with some people in the fintech world who indicated a minimum scale of 8 digits is a requirement. And further googling seems to suggest a widely used definition of numeric(20,8) to cover the ISO4217 currencies.

So the definition in the migration ended up with numeric(20,8). But over the last year I've come to agree with you that the definition is likely better with just numeric since it allows arbitrary precision and scale up to very very large numbers. The only cost is variable sized storage of numbers but that seems a reasonable cost to maintain precision.

Happy to hear comments from any other user of ex_money. If no comment, or unforeseen issue, I will change the definition for the provided migration in the next release.

You are also right that you should find no issues in changing the definition as you suggested above.