How can this be explained.
When you run Select * from myview where denominator = 0 it is resulting in a different execution plan than when you select from the view wide open with select * from myview or select * from myview order by denominator. That different execution plan likely has a different order of steps (physical operations) than the execution plans of the other wide open queries. The row where denominator = 0 that was previously being filtered out early on before the division operation, is now not being filtered out until after the division operation, resulting in a "divide by 0" error.
The SQL engine is allowed to re-arrange the order of physical operations under the hood, when processing a query, so long as the end result of rows is logically the same. Sometimes that results in issues like this, where a row that was previously being filtered out early on, and is now filtered out later on, but causes an invalid / error case in a computation.
If you wanted to provide the materialized view's definition, some sample data from it and the underlying tables behind it, and the execution plans of your queries via Paste The Plan, then more information can be provided on how to fix the issue.
