Re: type money causes unrestorable dump

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: type money causes unrestorable dump
Date: 2007-10-10 13:20:56
Message-ID: 14714.1192022456@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Long term I liked the idea from a few years ago of having a "default format"
> which would be attached to a column just like a default collation can be
> attached. Then you can declare your currency columns as regular integers but
> mark them as being formatted as currency by default.
> pg_dump would presumably explicitly override the default and format the
> integers as plain integers and restore the default format string as part of
> its DDL.

At least for the case at hand, this seems a pretty horrid solution. It
could easily lead to a value that had been $1.01 being reloaded as 101 Yen,
or vice versa, neither of which would make anyone happy.

If anything I would gripe that type money is not locale-specific enough;
it doesn't have a way to prevent similar confusions between say US$
and AU$, or any two currencies using the same symbol.

The better long-term solution would be to go over to a tagged-type
arrangement, in which each value is *explicitly* marked with its
currency. This needn't be a whole lot slower than the current
arrangement --- I think D'Arcy already took the main speed hit when
he went from int4 (pass by value) to int8 (pass by reference).

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-10-10 13:46:56 Re: Locale + encoding combinations
Previous Message Tom Lane 2007-10-10 13:04:55 Re: Timezone database changes