dividing money by money
in [PgSql]
|
From: "Kevin Grittner" on 16 Jul 2010 11:11 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > The only way I'd be willing to label those things immutable was if > we did something to lock down lc_monetary for the life of a > database (ie, make it work more like lc_collate does now). Which > might be a good idea, but it's not how it works today. Interesting. In general, what is involved in locking something like this down for the life of a database? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 16 Jul 2010 12:21 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> The only way I'd be willing to label those things immutable was if >> we did something to lock down lc_monetary for the life of a >> database (ie, make it work more like lc_collate does now). Which >> might be a good idea, but it's not how it works today. > Interesting. In general, what is involved in locking something like > this down for the life of a database? IIRC, the main pain point is providing an option for CREATE DATABASE to set the value. If you chase down all the references to lc_collate you'll get the picture. It'd probably be worth doing if money were less deprecated, but right now I can't get excited about it. Actually ... the thing that might turn money into a less deprecated type is if you could set lc_monetary per column. I wonder whether Peter's collation hack could be extended to deal with that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 16 Jul 2010 09:39 Tom Lane <tgl(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 16 Jul 2010 01:17 On tor, 2010-07-15 at 22:25 -0400, Tom Lane wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > > Andy Balholm <andy(a)balholm.com> wrote: > >> On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote: > >> I deleted the excess comments and moved some lines around. Here it > >> is with the changes. > > > I ran pgindent to standardize the white space. (No changes of > > substance.) Patch attached. > > > I'll mark it "Ready for Committer". > > Applied with some editorial changes. I didn't see any discussion about why this should return float8 rather than numeric. It seems wrong to use float8 for this. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 16 Jul 2010 10:43
"Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> * 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? Yeah, which is why I didn't feel that this was something that really needed back-patching, even though the markings have been wrong since the lc_monetary dependency was introduced. > 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? Well, whether people change the value in practice or not, it's still wrong to mark the functions more optimistically than the rules say. The only way I'd be willing to label those things immutable was if we did something to lock down lc_monetary for the life of a database (ie, make it work more like lc_collate does now). Which might be a good idea, but it's not how it works today. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |