Thread: Money type display

Money type display

From
darcy@druid.net (D'Arcy J.M. Cain)
Date:
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.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] Money type display

From
Brett McCormick
Date:
I say remove it.  It has only caused problems for me.  Also, what
about the convention of only having a $ in the first & last rows
instead of all in between.  there should at least be a handy function
for converting the output (other than string manipulation) should the
$ be left on..

On Fri, 27 February 1998, at 08:45:09, 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.
>
> --
> D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
> http://www.druid.net/darcy/                |  and a sheep voting on
> +1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Re: [HACKERS] Money type display

From
Jonathan Guthrie
Date:
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.

A while back, (nine months, actually) I wrote that there were a number of
problems with the money type.  I got several messages asking what I
thought was wrong.  I've been meaning to write that message, but I've
never found the time.  (The fact that I deleted my code for a currency
type when I saw that the money type was included with the distribution is
a major contributing factor, here.)

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.

I also thought that there should be some way of formatting the output for
different locales and that there should be some canonical format to be
used for dumps and such to avoid the problem of dumping in one locale and
attempting a reload in a different locale.  This is kind of related to
your question.

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.

HTH.

--
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.