We allow mapping functions (both by providers and by users), and treat these like any other expression node in the query tree. However, functions are unique among SQL nodes in that they can have side-effects, so either removing them (because of an optimization) or duplicating them (e.g. to add a null check) could lead to data corruption.
One possibility here is to assume functions are pure (no side effects), but allow users to tell us that they are non-pure. In that case, we'd avoid optimizing the call away, and throw in cases where duplicating it would be necessary to translate correctly.
Note: regardless of functions and side effects, it seems to be we should be very wary of duplicating subtrees of unknown depth/contents in the query (because of the perf impact).
We allow mapping functions (both by providers and by users), and treat these like any other expression node in the query tree. However, functions are unique among SQL nodes in that they can have side-effects, so either removing them (because of an optimization) or duplicating them (e.g. to add a null check) could lead to data corruption.
One possibility here is to assume functions are pure (no side effects), but allow users to tell us that they are non-pure. In that case, we'd avoid optimizing the call away, and throw in cases where duplicating it would be necessary to translate correctly.
Note: regardless of functions and side effects, it seems to be we should be very wary of duplicating subtrees of unknown depth/contents in the query (because of the perf impact).