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
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 |