Tom Lane <t...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
