I have noticed that when float types are divided by zero in a query, the
the query aborts (via elog(WARN)) with a complaint about divide by zero.
Also an integer divide by zero produces a result. On our AIX 4.1.4
system 1 / 0 = 15. And 10 / 0 = 31. There is some pattern here with
integers, but it is of little use.
I have two assertions that I would like to make.
1. The result of these numeric division queries should be consistent.
If one aborts, then they probably should both abort.
2. I don't think that division by zero should abort.
This problem was brought to my attention by a user the was computing
"Percent Profit". Profit / Net = %Profit. It is considered
reasonable, in sales circles, to offer a free line item on an invoice.
Thus, the calculation becomes (Profit / 0).
I am suggesting that something be returned on a divide by zero.
Possible return values for float types include NULL and INFINITY. An
elog(NOTICE) may also be sent. Of the two possibilities NULL would be
relativity easy. Simply detect the offending division, send a NOTICE,
and return null. INFINITY, on the other hand, would be a bit more
tricky. This may involve some platform porting issues. Plus INFINITY
would have to be handled by each function that processes float numbers.
Integer type functions, however, appear not to be capable of returning
anything other than a legal integer. They are passed by value. I can
only come up with one possibility. That would be to reserve one of the
boundary values, such as MAX_INT, to represent INFINITY (or NULL for
that matter) and handle the max value in each integer function. I
would think, though, that on a detected divide by zero there should at
least be an elog(WARN).
I must resolve the problem at my site. And I would like to contribute
these change, assuming they are acceptable to the other hackers.
Suggestions?
