Re: dividing money by money

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: dividing money by money
Дата
Msg-id 4C401AAD02000025000336F4@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: dividing money by money  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: dividing money by money  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> * I didn't like this bit in cash_numeric():
> 
>     result->n_sign_dscale = NUMERIC_SIGN(result) | fpoint;
> 
> Not only is that unwarranted chumminess with the implementation of
> numeric, it's flat-out wrong.  If the result isn't exactly the
> right number of digits (say, it's 12.33999999 instead of the
> desired 12.34) this just hides the extra digits, it doesn't make
> the result correct.  The right way is to use numeric_round(),
> which not only sets the dscale where we want it but rounds off any
> inaccuracy that might have crept in from the division.
Thanks.  Duly noted.
> * The cast functions were marked immutable, which is wrong because
> they depend on the setting of lc_monetary.  The right marking is
> "stable".
Is there any impact of the change to lc_monetary which would matter
besides the number of decimal positions?  If that changes, isn't
every money amount in the database instantly made incorrect?  If so,
I'm dubious that marking this as stable is worthwhile -- if someone
is making a change like that, they will need to update all money
amounts in the database; reindexing would be the least of their
problems.  Or am I missing some other effect?
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: reducing NUMERIC size for 9.1
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: argument to pg_get_expr() must come from system catalogs