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

>
> > > > 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.

-dg

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)