Re: [HACKERS] Division by Zero
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Division by Zero |
Дата | |
Msg-id | 353408A4.9C5D09F3@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Division by Zero (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian wrote: > > > > > This is a multi-part message in MIME format. > > --------------0BE30DC54DE04265764E3F7C > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > 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. > > On BSDI: > > test=> select 1/0; > ERROR: floating point exception! The last floating point operation > either exceeded legal ranges or was a divide by zero > > I think a transaction abort is the only normal solution. I get the same behavior on my Linux box, so at least we have consistant behavior across some platforms! David, if you want to find out what it takes to change the floating point exception handling to allow divide-by-zero and to have integer overflows caught be an exception handler, then we can discuss what the default behavior should be. If it is a simple matter of throwing an exception and catching it, then perhaps we can make it a compile-time or run-time option. With IEEE arithmetic, infinity results for floats are possible. I don't really like uncaught integer overflows which is what we have now... tgl=> select 2000000000*2; ---------- -294967296 (1 row) Don't know where else integer overflows might be used in the backend, so we would have to do extensive testing. - Tom
В списке pgsql-hackers по дате отправления: