Re: numeric/decimal docs bug?

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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026