Re: Fixed length data types issue - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Fixed length data types issue
Date
Msg-id 87pse2ovh3.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Fixed length data types issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixed length data types issue  (mark@mark.mielke.cc)
Re: Fixed length data types issue  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
> > At first I meant that as a reductio ad absurdum argument, but, uh,
> > come to think of it why *do* we have our own arbitrary precision
> > library? Is there any particular reason we can't use one of the
> > existing binary implementations?
> 
> Going over to binary storage would trade off I/O speed for calculation
> speed, which is probably not a win for everyone; 

Huh? Which would you expect binary to be worse at than decimal? I would expect
it to be both faster and denser.

> and even more seriously, how are you going to represent decimal fractions
> exactly? The fact that 0.01 is 0.01 and not just a near approximation
> thereto is critical for a lot of our users.

Certainly any arbitrary precision library isn't worth beans if it can't
represent values accurately.

I'm not sure how gmp and the others represent their data but my first guess is
that there's no particular reason the base of the mantissa and exponent have
to be the same as the base the exponent is interpreted as. That is, you can
store a base 10 exponent but store it and the mantissa in two's complement
integers.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixed length data types issue
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Fixed length data types issue