Re: [HACKERS] Money type display

> On Fri, 27 Feb 1998, D'Arcy J.M. Cain wrote:
>
> > I wonder if I didn't make a mistake in the money type. As a C library
> > function it made sense to add the "$" to the display because it was
> > easy to add one to the return value if it wasn't required. I'm finding
> > it to be a bit of a problem with my Python interface. I was just
> > going to strip it in my module but I thought I would see if others
> > felt that it should simply be dropped from the PostgreSQL output.
>
...

> In a nutshell, there were two problems: it didn't handle the case where
> locales were defined for the build, but not for the run. Also, the
> output didn't make use of all of the features of the locale, though I
> don't recall the details of that complaint.
>
...

> Lately, I've been thinking of building some Python classes to support
> certain Web-based operations on databases. (I do lots of active Web
> pages
> based upon Postgres databases.) I was going to have a class for money
> fields, but I wasn't going to use the Postgres currency class. This
> was
> because the fact that I wanted Postgres to handle the value, with the
> Python handling the formatting of the output. It seems like such a
> waste
> to have the Postgres back end do all this formatting only to have some
> other code parse it so that I could manipulate the value and then
> reformat
> it. I don't particularly want to do all the arithmetic in SQL.

I think that using locales in _backend_ is a _bad_thing_ in general.
AFAIK unix (and C libraries) do not use locales in storage of the data
but only representation. And as the representation is done in the
front-end, it only introduces additional problems if we have the
protocol changing depending on locales (of both front-end and back-end).
It is a good thing to have an ASCII protocol, especially for debugging,
but also for ease of implementing new frontends, but it should not
change for random causes. So the input and output functions for types
should _not_ use locales at all.

--------------------------
Hannu Krosing

>