Re: numeric/decimal docs bug? - Mailing list pgsql-hackers

Bruce Momjian wrote:
> Jan Wieck wrote:
> >
> >     I missed some of the discussion,  because  I  considered  the
> >     1,000 digits already beeing complete nonsense and dropped the
> >     thread. So could someone please enlighten me  what  the  real
> >     reason  for  increasing  our  precision  is?   AFAIR  it  had
> >     something to do with the docs. If it's just because the  docs
> >     and  the code aren't in sync, I'd vote for changing the docs.
>
> I have done a little more research on this.  If you create a numeric
> with no precision:
>
>    CREATE TABLE test (x numeric);
>
> You can insert numerics that are greater in length that 1000 digits:
>
>    INSERT INTO test values ('1111(continues 1010 times)');
>
> You can even do computations on it:
>
>    SELECT x+1 FROM test;
>
> 1000 is pretty arbitrary.  If we can handle 1000, I can't see how larger
> values somehow could fail.
   And  I  can't  see  what more than 1,000 digits would be good   for.  Bruce, your research is neat, but IMHO wasted
time.
   Why do we need to change it now? Is the more important  issue   (doing  the  internal  storage representation in
base10,000,   done yet? If not, we can open up for unlimited  precision  at   that time.
 
   Please,  adjust the docs for now, drop the issue and let's do   something useful.

> Also, the numeric regression tests takes much longer than the other
> tests.  I don't see why a test of that length is required, compared to
> the other tests.  Probably time to pair it back a little.
   What exactly do you mean with "pair it back"?  Shrinking  the   precision   of   the   test  or  reducing  it's
coverage of   functionality?
 
   For the former, it only uses 10 of the possible 1,000  digits   after  the  decimal  point.   Run the numeric_big
test(which   uses  800)  at  least  once  and  you'll  see  what  kind  of   difference precision makes.
 
   And  on  functionality,  it  is  absolutely  insufficient for   numerical functionality that  has  possible  carry,
rounding  etc.  issues,  to  check a function just for one single known   value, and if it computes that result
correctly,consider  it   OK for everything.
 
   I  thought  the  actual  test  is sloppy already ... but it's   still too much for you ... hmmmm.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #