Withing PG procedures at least in pgsql it is impossible to do 'money' calculations without a loss of precision. There is an open source library by IBM that I use in my C++ code to do this, and may be it can be incorporated into PG it is called decNumber http://speleotrove.com/decimal/decnumber.html Micropayment systems (that for example, I am implementing) require to have a reasonably good precision. Support for currencies such as yen also dictates that reasonably large numbers are supported in my case, all my money calculations are done in C++ using decNumber (which makes the only useful feature of Cobol be available in C++ :-) ) then I convert them to a string, and send via Postgres ODBC to NUMBER (19,6) field (Postgres ODBC driver does not support a 'naitive' number type, so I convert to text). On Sat, 03 Oct 2009 17:19 +0100, "Sam Mason" <sam@xxxxxxxxxxxxx> wrote: > On Sat, Oct 03, 2009 at 11:49:50AM -0400, Merlin Moncure wrote: > > On Sat, Oct 3, 2009 at 11:40 AM, Sam Mason <sam@xxxxxxxxxxxxx> wrote: > > > it's still a computer and thus can't represent anything > > > with infinite precision (just numeric fractions in PG's case, let alone > > > irrational numbers). > > > > I don't quite agree with your statement (I agree with your point, just > > not the way you worded it). > > Maybe I didn't emphasize "numeric" enough; the current implementation > of numeric datatypes in PG does not allow fractions to be represented > accurately. Is that any better? > > > I could make a type, 'rational', define > > the numerator, denominator, and do calculations like the above with > > zero loss. > > Yes, if you defined a datatype like this then it would be able to > express a strictly larger subset of all numbers. > > > So it depends how you define 'represent'. > > Computers can do pretty much any type of bounded calculation given > > enough time and memory. > > Which is why I said "with infinite precision". Assuming infinite time > or space doesn't seem to help with any real world problem, it's the > details of the assumptions made and the use case(s) optimized for that > tend to be interesting. > > -- > Sam http://samason.me.uk/ > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Vlad P author of C++ ORM http://github.com/vladp/CppOrm/tree/master -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
