Agreed, RelBuilder should validate function arguments. I’ve logged https://issues.apache.org/jira/browse/CALCITE-1073.
Usually calls are validated using SqlValidator.validateCall, which delegates to the following policies inside the operator: private final SqlReturnTypeInference returnTypeInference; private final SqlOperandTypeInference operandTypeInference; private final SqlOperandTypeChecker operandTypeChecker; There isn’t a SqlValidator accessible to RelBuilder, but I think we can somehow make RelBuilder call into the policies. Julian > On Feb 1, 2016, at 3:13 PM, Fabian Hueske <[email protected]> wrote: > > Hi, > > I am using Calcite's RelBuilder to directly generate Calcite RelNodes from > Flink Table API calls [1]. > The translations works very well and was pretty straightforward to > implement, however it looks like the RelBuilder does not thoroughly > validate the generated expressions. > It ensures that field expressions can be resolved, but does for example not > check the types in expressions (for example it accepts a SUBSTRING(String, > String, Float) expression). > > I've seen that Calcite usually validates SQL queries before they are > translated to RelNodes in the SQLNode representation. By calling the > RelBuilder, I am bypassing these phases. > > I could implement the checks before calling the RelBuilder myself, but it > would be easier if Calcite could validate the RelNodes and their > expressions. Is this somehow possible? > > Thanks, Fabian > > [1] > https://ci.apache.org/projects/flink/flink-docs-release-0.10/libs/table.html
