What's wrong with that? It's mathematicaly undefined. SQL dialects typically return NULL for erroneous operations. Plus, it's not like it's returning 0 or some other numeric-typed value

If all the inputs to the expression are not null, you should get some not null result so long as your well defined inputs meet other criteria of the expression (in bounds, etc.); I'd consider this a validation question and, failing validation, I'd want an exception. By simply returning NULL, you're really saying something else... that the inputs to the expression are valid, but result in something that cannot be determined. I don't think this is the case in 1/0; an exception is the proper signal since the construction of the expression itself is wrong (or the inputs invalid).

"SQL dialects typically return NULL for erroneous operations." I disagree with this. NULL does not mean erroneous, it simply means the definition is not yet known and therefore cannot be discussed beyond saying you don't know. That could be erroneous, but you don't know yet, all you have is a NULL.

If it's any comfort, I do agree that NULL is better than 0 or some other non-null result. I just don't think it's best and clouds the nature of the expression, the inputs to the expression, and ultimately is an incorrect result.

Also to be fair, MySQL had many more grievous foot-gun data quality issues in the past than this... though these things certainly did make it easier for a non-expert database developer to get something working without blow-up-everything errors.

My understanding was that it's "not allowed" rather than "undefined".

SQL returns NULL if any input value into an expression is NULL, not if an invalid operation is attempted. If the expression contains an error, SQL throws an error, it doesn't return NULL.

The SQL standard requires to error out in this case.

Also: I don't know of any system that would not result in an error when you try to divide something by zero.