Re: Reducing the overhead of NUMERIC data

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing the overhead of NUMERIC data
Date: 2005-11-04 21:18:18
Message-ID: 20051104211818.GZ9989@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Thu, Nov 03, 2005 at 10:32:03AM -0500, Tom Lane wrote:
> I'd feel a lot happier about this if we could keep the dynamic range
> up to, say, 10^512 so that it's still true that NUMERIC can be a
> universal parse-time representation. That would also make it even
> more unlikely that anyone would complain about loss of functionality.

Would it be feasable to have a type that satisfies that constraint but
isn't generally intended for on-disk use? My thought is that this new
type would be used mostly for casting purposes. Kind of like the
UNKNOWNNUMBER but easier to do since it'd just be another type. (BTW,
I'm not suggesting that we disallow un-disk storage of the type, only
discourage it unless someone really, really needs an absurd number of
digits).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-11-04 21:25:22 Re: Assert failure found in 8.1RC1
Previous Message Gurjeet Singh 2005-11-04 21:15:59 Re: roundoff problem in time datatype

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-11-04 21:30:27 Re: Reducing the overhead of NUMERIC data
Previous Message Gurjeet Singh 2005-11-04 21:15:59 Re: roundoff problem in time datatype