Juilian>Hey, folks. We need your input here. Here are my thoughts: 1) I think the features we add should have at least some level of consistency 2) It is much safer to adopt well-known features rather than be pioneers in the field. I do not mean we must wait for someone else implement and try out a feature, however I would not rush for implementing a feature that no-one else explored.
CALCITE-525 has two key points: A) Current implementation of enumerable factors code like 0/0 to a static field of a generated code. It causes the generated code to fail at load time even before the query is executed. Of course that is a bug, and I'm even inclined to remove that "static fields" B) Someone (Hongze? Juilan?) suggest to implement a mode to silently ignore the error (e.g. by ignoring the row or by returning default value). First of all, I don't think "ignore the row" kind of processing would do any good to the user since it would not be possible to predict the output. "ignore the row" is very tricky when join/semijoin/antijoin is there. I'm sure OracleDB and PostgreSQL do NOT have such "features", so I think we should not rush for it. C) Hongze suggests CATCH_ERROR(1 / 0 EMPTY ON ERROR) or CATCH_ERROR(1 / 0) EMPTY ON ERROR kind of functions. That enables to confine the scope of the error, however I don't think it would be used often (does that mean one would have to wrap each expression?), and this "catch error" would be non-trivial to propagate to the downstream executors. On top of that, we might end up inventing full-blown try-catch-catch-catch syntax. I truly see no business value in implementing B/C, however I do see the pain it would introduce. It would complicate Calcite maintenance. "B" could silently produce wrong results, and I'm sure we don't want get results out of thin air. Vladimir
