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@samason.me.uk> 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@samason.me.uk> 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@postgresql.org)
> 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