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 22:05:07
Message-ID: 20051104220507.GC9989@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Fri, Nov 04, 2005 at 04:30:27PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > 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.
>
> What exactly would be easier about it? ISTM you just described
> UNKNOWNNUMERIC to a T.

Apologies then; it sounded like UNKNOWNNUMERIC was going to be something
that was internal-use only, presumably making it much harder to
implement than just adding an additional type.
--
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-11-04 22:08:52 Re: Assert failure found in 8.1RC1
Previous Message Jim C. Nasby 2005-11-04 22:02:13 Re: Exclusive lock for database rename

Browse pgsql-patches by date

  From Date Subject
Next Message Martijn van Oosterhout 2005-11-04 23:40:33 Re: Reducing the overhead of NUMERIC data
Previous Message Tom Lane 2005-11-04 21:30:27 Re: Reducing the overhead of NUMERIC data