[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception-handling in built-in functions

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
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

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

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.