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 wi
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
c
"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 w
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( endb
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 quest
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 (pg
