On 6/8/08, Gregory Stark [EMAIL PROTECTED] wrote:
I don't think as late as possible applies with money. If you were dealing
with approximate measurements you want to round as late as possible because
rounding is throwing away precision. But if you're dealing with money you're
dealing with
Gregory Stark wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
IFAIK (dimly recalling numerical analysis courses at university) SUM and ROUND
can *never* be commuted. In general the recommended approach is to round as
late as possible and as few times are possible - so your 1st query is the
Mark Kirkwood [EMAIL PROTECTED] writes:
IFAIK (dimly recalling numerical analysis courses at university) SUM and ROUND
can *never* be commuted. In general the recommended approach is to round as
late as possible and as few times are possible - so your 1st query is the
correct or best way to
I believe i have found a math bug/rounding problem with Money type when
its used with SUM()... Postgresql 8.3.1
--- Background on the Problem
We have gl_trans table with 92,000 rows with one column containing the
positive and negative entries.
In order to
Justin [EMAIL PROTECTED] writes:
I believe i have found a math bug/rounding problem with Money type when
its used with SUM()... Postgresql 8.3.1
You do know that money only stores two fractional digits?
regards, tom lane
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
Justin [EMAIL PROTECTED] writes:
I believe i have found a math bug/rounding problem with Money type when
its used with SUM()... Postgresql 8.3.1
You do know that money only stores two fractional digits?
regards, tom lane
yes. The
Justin wrote:
yes. The question is why are the to sides not equal anymore
Take this
Select
'2',
round(sum( beginBalance ),6) as beginbalance,
round(sum( negative ),6) as debit,
round(sum( positive ),6) as credit,
round(sum( difference ),6) as difference,
round(sum(
