>
> > The only ugly thing is, that I needed to put the precision
> > AND the scale together into atttypmod (I limited both to 99
> > for now and put them as prec<<8 | scale into). So pg_dump
> > will need attention later.
>
> Atttypmod was expanded to 32 bits for exactly that use. I recommend
> 16-bits for each option.
I tried that first and it failed. Now that you said that,
I've found in nodes/parsenodes.h that the typmod field of
TypeName is still int16.
I'll change that to int32 after having checked that it
doesn't break anything.
I also read the comment from Oleg about the other numeric
package out. Haven't taken a look at it, but I think for
Postgres I would have to build a complete new set of
functions from scratch anyway. The reasons for that are:
1. I want to store the digits of the NUMERIC type as nibbles
in the tuple to save space (so it will become a real
packed format). My first hack used one byte per digit and
I think it's wasted space.
2. I want to use the VARSIZE, one combined int16 holding the
sign and the number of digits before the decimal point
and one int16 holding the digits to DISPLAY after the
decimal point as metadata describing the precision and
calc-/display scale.
None of the packages I've seen up to now has a separate
DISPLAY scale in the number itself. They all use some
global scale variable.
3. The packed internal format will need to be
unpacked/packed for speed on complex operations (divide,
multiply, log etc.). While add and subtract should be
possible directly on the packed format.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #