One of the items on the commit-fest list is my patch from last year
to rewrite the numeric division operator using "schoolbook division":
http://archives.postgresql.org/pgsql-patches/2007-06/msg00173.php
The code that's currently in there sometimes has to propagate rounding
to the left, meaning that you can never be certain whether all of the
digits you have so far are good, and that means that it can sometimes
generate an incorrect truncated output. This leads to the bugs cited
in the above message.
The reason I didn't just commit it last year is that I was dissatisfied
with the speed penalty --- on very long inputs (dozens or hundreds of
digits) division is about 4X slower than with our existing code.
However, no one has come up with a better answer; and as a wise man once
said, "I can make this program arbitrarily fast, if it doesn't have to
give the right answer". Correctness has to trump speed.
One thing that occurs to me is that we could keep the existing
"approximate division" code in there too, and use it internally in the
transcendental function implementations. Those are not particularly
interested in getting exact truncated results, and they are the worst
case for the speed penalty because they do lots of divisions on values
that are likely to be long. However this idea could fairly be charged
with being code bloat.
Comments?
Also, there was some discussion of providing a SQL-level numeric
"integer division" operator or function, that is the equivalent of
trunc(x/y) except faster (since it'd not need to compute fractional
digits that would then be thrown away). Is this worth doing, and if so
what should we call it exactly? The amount of new code needed should
be pretty small (just an interface function), so I'm willing to take
care of it if we want one.
regards, tom lane
