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

From Gregory Stark
Subject Re: Fixed length data types issue
Date
Msg-id 87lkoqul8a.fsf@enterprisedb.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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> That's utterly irrelevant.  The point is that there are standard
> applications today in which people need that much precision; therefore,
> the argument that "10^508 is far more than anyone could want" is on
> exceedingly shaky ground.

My point is those applications aren't practical in our current implementation
and we can always extend the precision later if we decide we want it to be.

> Besides, isn't "it's too slow" a bug we'd like to fix someday?

The only way I see to do that is to replace our implementation entirely with
something like libgmp.

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?

I think libgmp itself is GPL'd but there are others and even if libgmp is
GPL'd that just puts it into the same camp as readline. It would have to be an
option and even the strictest interpretations of the GPL as long as there are
alternative implementations it's fine.

I was going to spend time looking at optimising numeric's storage but it seems
like a waste of time if we could just use an implementation that's better.

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


pgsql-hackers by date:

Previous
From: "Luke Lonergan"
Date:
Subject: Re: New job
Next
From: Kevin Brown
Date:
Subject: Re: [PATCHES] Fix linking of OpenLDAP libraries