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

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

From: dg(at)illustra(dot)com (David Gould)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, 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 23:49:05
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

Int32 is fine with me. Or maybe uint32? Or maybe

union {
  u uint32;
  struct {
    h int16;
    l int16;

Oh no, it is happening again....

Lets just go with uint32.


David Gould            dg(at)illustra(dot)com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Of course, someone who knows more about this will correct me if I'm wrong,
 and someone who knows less will correct me if I'm right."
               --David Palmer (palmer(at)tybalt(dot)caltech(dot)edu)

In response to


pgsql-hackers by date

Next:From: Brett McCormickDate: 1998-06-01 00:23:16
Subject: Re: [HACKERS] regular expressions from hell
Previous:From: David GouldDate: 1998-05-31 23:46:30
Subject: Re: [HACKERS] regular expressions from hell

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