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