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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers