Hey Ian,

If the SqlOperator implements the ImplementableFunction [1] interface then
you may be able to use the RexExecutor [2] but I assume you already
explored this direction.
I am not sure if there is an easier way to achieve this.

Best,
Stamatis

[1]
https://github.com/apache/calcite/blob/28c5881c8de10751b415aaf3e3f50b3168c893d3/core/src/main/java/org/apache/calcite/schema/ImplementableFunction.java
[2]
https://github.com/apache/calcite/blob/28c5881c8de10751b415aaf3e3f50b3168c893d3/core/src/main/java/org/apache/calcite/adapter/enumerable/RexImpTable.java#L856

On Fri, Nov 11, 2022 at 1:11 AM Ian Bertolacci
<[email protected]> wrote:

> Howdy,
> I’m playing around with some testing expressions after transformation, and
> would like to use RexExecutor to evaluate\* the original expression and
> expression resulting from the transformation.
> (\*these expressions do not have input refs or any other kinds of
> “free-variables”)
> However, this transformation specifically and intentionally inserts
> SqlOperators which RexExecutor (specifically RexToLixTranslator) does not
> know how to implement, and fails.
> RexToLixTranslator asks RexImpTable.INSTANCE for the implementation of the
> operators, but I cant see any way to give RexImpTable.INSTANCE an
> implementation of an operator.
>
> Any guidance?
> Right now I’m using the simple RexUtil.EXECUTOR, but I’m getting the
> feeling that this is a situation where I need to construct a RexExecutor
> from scratch with a DataContext that has a Schema with those Functions
> defined.
> Would doing so allow the RexExecutor to implement these non-standard
> operators?
>
> Thanks!
> -Ian J. Bertolacci
>

Reply via email to