Re: monetary bug

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> > It seems to me a monetary type is a complex type consisting of currency
> > code and amount -- but you couldn't sum mixed currencies. Or else it is
> > limited to the currency of the locale, which doesn't seem particularly
> > useful.
>
> In a former lifetime I worked with databases involving amounts of
> different currencies, and I didn't find type money useful for that
> either. But I think that's a specialized requirement and we'd be
> unlikely to consider putting a type that *is* useful for that into
> the standard distribution.

Actually I think dimensioned values, or quantities with units attached, would
be a very useful datatype for lots of purposes. Both accounting and scientific
purposes often need to store things in heterogenous units but then be sure not
to perform any inappropriate operations on them. Even if it just asserted that
the units matched and permitted the operation it would be useful, without
trying to do any fancy dimensional calculus to come up with things like m^2 or
m/s etc.

fwiw, I agree with the other poster that data types ought to be defined by the
operations performed on them, not the display format. In particular I would
expect the application to be able to multiply or add to a value pulled from a
database even if it's a monetary value, and that wouldn't work if the database
insisted on attaching units. It should be the job of strfmon or equivalent to
format the value for display.

Perhaps what people are really looking for is some kind of column attribute to
define the "default" display format to be used. So that applications don't
have to hard code parameters to to_char(). There are solutions at the
application layer for that, but I could see it being useful to be able to call
to_char(column) and have the column know which parameters by default whether
it's a date column, numeric column, or cidr datatype.

--
greg