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

Re: [HACKERS] Upgrades for 6.4.1

From: jwieck(at)debis(dot)com (Jan Wieck)
To: maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian)
Cc: jwieck(at)debis(dot)com, hannu(at)trust(dot)ee, lockhart(at)alumni(dot)caltech(dot)edu, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Upgrades for 6.4.1
Date: 1998-12-21 13:00:34
Message-ID: m0zs4wt-000EBUC@orion.SAPserv.Hamburg.dsh.de (view raw or flat)
Thread:
Lists: pgsql-hackers
>
> >     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(at)debis(dot)com (Jan Wieck) #



In response to

pgsql-hackers by date

Next:From: D'Arcy J.M. CainDate: 1998-12-21 16:11:25
Subject: Python interface
Previous:From: Jan WieckDate: 1998-12-21 10:42:38
Subject: Re: [HACKERS] Is this a bug? or am I doing some thing wrong?

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