Money type display

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.

Remove it! Those of us who aren't American/Canadian/Australian don't want
a dollar sign for money anyway :-)

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

Thus spake Andrew Martin

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.

Remove it! Those of us who aren't American/Canadian/Australian don't want
a dollar sign for money anyway :-)

Right. The original code that that comes from used locale extensively
for things like that.

Also, what about the commas? Again, locale is supposed to be used to
determine which character to use but I am sure it just causes confusion.

In fact, perhaps we should just turn the money code into the decimal
type. I understand we have a mechanism now for specifying an argument
to the input and output functions so we can specify the precision of
the decimal. Is this correct? If someone can help me out with the
type specifications, I'll start creating the code to handle decimal
types. I'll just take the money code and modify it.

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

In fact, perhaps we should just turn the money code into the decimal
type. I understand we have a mechanism now for specifying an argument
to the input and output functions so we can specify the precision of
the decimal. Is this correct? If someone can help me out with the
type specifications, I'll start creating the code to handle decimal
types. I'll just take the money code and modify it.

Yep, it's in there. atttypmod is passed to all input/output function as
the third argument.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

What's the second argument?

On Fri, 27 February 1998, at 12:19:34, Bruce Momjian wrote:

What's the second argument?

On Fri, 27 February 1998, at 12:19:34, Bruce Momjian wrote:

Yep, it's in there. atttypmod is passed to all input/output function as
the third argument.

If it is an array, and the base type.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

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.

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