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

Jan Wieck wrote:
> 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 base 10,000,
>     done yet? If not, we can open up for unlimited  precision  at
>     that time.

I certainly would like the 10,000 change done, but few of us are
capable of doing it.  :-(

>     Please,  adjust the docs for now, drop the issue and let's do
>     something useful.

Thats how I got started.  The problem is that the limit isn't 1,000. 
Looking at NUMERIC_MAX_PRECISION, I see it used in gram.y to prevent
creation of NUMERIC columns that exceed the maximum length, and I see it
used in numeric.c to prevent exponients that exceed the maximum length,
but I don't see other cases that would actually enforce the limit in
INSERT and other cases.

Remember how people complained when I said "unlimited" in the FAQ for
some items that actually had a limit.  Well, in this case, we have a
limit that is only enforced in some places.  I would like to see this
cleared up on way or the other so the docs would be correct.

Jan, any chance on doing the 10,000 change in your spare time?  ;-)


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

Well, our regression tests are not intended to test every possible
NUMERIC combination, just a resonable subset.  As it is now, I often
think the regression tests have hung because numeric takes so much
longer than any of the other tests.  We have had this code in there for
a while now, and it is not OS-specific stuff, so I think we should just
pair it back so we know it is working.  We already have bignumeric for a
larger test.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026