ahh, so 6.5 has an answer! for our "cash and accounts payable" database i
converted the float4 field to int4, and altered the input mask on the front
end to show a decimal point, but not save it with the data. so now i am
saving $35.99 as 3599. i had to alter all reports to divide by 100. works
fine. i'd really like to get it sincerely stable in 6.4.2 before upgrading
to 6.5, unless a reason for instability is solved in 6.5. we are still
having problems with it locking up daily. . .
jt
-----Original Message-----
From: Tom Lane [SMTP:[EMAIL PROTECTED]]
Sent: Monday, June 28, 1999 7:32 PM
To: JT Kirkpatrick
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: Re: [SQL] float4
JT Kirkpatrick <[EMAIL PROTECTED]> writes:
> we made all monetary fields FLOAT4's. weird stuff -- or maybe not to you
> -- we insert 23516.69 into a float4 field directly in psql, and then
select
> it, and it shows 23516.7. this is not good for a field used for MONEY!!!
Yup, no surprise. float4 is good to about 6 decimal digits on most
machines, and yours is evidently right in there with the pack.
float8 is good to about 16 digits on most hardware, but I wouldn't
really recommend it either if you need guaranteed-exact calculations.
The money type in Postgres is a fairly crude hack that I can't recommend
(it's basically an int4 representing cents, and will therefore poop out
at 2^31 cents or about $20million).
What you really want is the general "numeric" type added in Postgres 6.5
--- decimal representation with as many digit positions as you specify.
It's a good deal slower for calculations than native floats,
unfortunately, especially if you use a very wide numeric field.
But calculations per-se are seldom the bottleneck for a database
application...
BTW, the current plan is to phase out the money type in favor of numeric
in some future release.
regards, tom lane
