Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patch

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: David Gould <dg(at)illustra(dot)com>, tgl(at)sss(dot)pgh(dot)pa(dot)us, hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Re: [DOCS] Re: FE/BE protocol revision patch
Date: 1998-05-31 16:08:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > > Comments?  I am willing to change it.
> >
> > An int 4 atttypmod should be fine. A bit of overhead perhaps, but 
> > who quibles about a few bytes these days? And, perhaps there is a 
> > use.
> Yea, no one commented, so it stays an int2 until someone finds a type
> that needs more than a two-byte atttypmod.  Right now, it fits the 
> need.

Well, I didn't comment because I haven't yet worked out the issues. But
I'll go with Bruce's and David's inclination that we should shoehorn
numeric()/decimal() into something like the existing atttypmod field
rather than trying for "the general solution" which btw isn't obvious
how to do.

However, I don't think that 16 bits vs 32 bits is an issue at all
performance-wise, and I'd to see atttypmod go to 32 bits just to give a
little breathing room. I'm already using int32 to send attypmod to the
new char/varchar sizing functions.

Can we go to int32 on atttypmod? I'll try to break it up into two
sub-fields to implement numeric().

btw, anyone know of a package for variable- and large-precision
numerics? I have looked at the GNU gmp package, but it looks to me that
it probably won't fit into the db backend without lots of overhead. Will
probably try to use the int64 package in contrib for now...

                      - Tom

In response to


pgsql-hackers by date

Next:From: Thomas G. LockhartDate: 1998-05-31 17:30:22
Subject: Re: [HACKERS] regular expressions from hell
Previous:From: The Hermit HackerDate: 1998-05-31 15:58:30
Subject: Re: [HACKERS] anon cvs and specific versions/releases

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group