Thanks for the quick response and creating the issue. Let me know if I can help.
Best, Fabian 2016-02-02 3:39 GMT+01:00 Julian Hyde <[email protected]>: > 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 > >
