[ https://issues.apache.org/jira/browse/FLINK-31182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692450#comment-17692450 ]
Jane Chan edited comment on FLINK-31182 at 2/23/23 6:08 AM: ------------------------------------------------------------ [~Sergey Nuyanzin] Yes, the check on the output type inference strategy was introduced in FunctionCatalogTableOperator in FLINK-15487 for FLIP-65 a long time ago. I guess it worked well before FLIP-190 was introduced because`LogicalUnnestRule` will infer the output type and convert UNNEST to EXPLODE. (see [LogicalUnnestRule L#99|https://github.com/apache/flink/blob/master/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/rules/logical/LogicalUnnestRule.scala#L99]). As a result, although the BuiltinFunctionDefinition for UNNEST always has a "MISSING" type inference, it does not affect the execution. However, after CompiledPlan is introduced, RexNodeJsonDeserializer relies on the OperatorTable to lookup functions, which always get a static placeholder (i.e. MISSING) for UNNEST, and due to this check, the deserialization failed. Could you help to take a look, cc [~godfreyhe] and [~twalthr] was (Author: qingyue): [~Sergey Nuyanzin] Yes, the check on the output type inference strategy was introduced in FunctionCatalogTableOperator in FLINK-15487 for FLIP-65 a long time ago. I guess it worked well before FLIP-190 was introduced because`LogicalUnnestRule` will infer the output type and convert UNNEST to EXPLODE. (see [LogicalUnnestRule L#99|https://github.com/apache/flink/blob/master/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/rules/logical/LogicalUnnestRule.scala#L99]). As a result, although the BuiltinFunctionDefinition for UNNEST always has a "MISSING" type inference, it does not affect the execution. However, after CompiledPlan is introduced, RexNodeJsonDeserializer relies on the OperatorTable to lookup functions, which always get a static placeholder (i.e. MISSING) for UNNEST, and due to this check, the deserialization failed. > CompiledPlan cannot deserialize BridgingSqlFunction with MissingTypeStrategy > ---------------------------------------------------------------------------- > > Key: FLINK-31182 > URL: https://issues.apache.org/jira/browse/FLINK-31182 > Project: Flink > Issue Type: Bug > Components: Table SQL / Planner > Affects Versions: 1.17.0, 1.18.0, 1.17.1 > Reporter: Jane Chan > Priority: Major > Attachments: screenshot-1.png > > > This issue is reported from the [user mail > list|https://lists.apache.org/thread/y6fgzyx330omhkr40376knw8k4oczz3s]. > The stacktrace is > {code:java} > Unable to find source-code formatter for language: text. Available languages > are: actionscript, ada, applescript, bash, c, c#, c++, cpp, css, erlang, go, > groovy, haskell, html, java, javascript, js, json, lua, none, nyan, objc, > perl, php, python, r, rainbow, ruby, scala, sh, sql, swift, visualbasic, xml, > yamlCaused by: org.apache.flink.table.api.TableException: Could not resolve > internal system function '$UNNEST_ROWS$1'. This is a bug, please file an > issue. > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserializeInternalFunction(RexNodeJsonDeserializer.java:392) > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserializeSqlOperator(RexNodeJsonDeserializer.java:337) > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserializeCall(RexNodeJsonDeserializer.java:307) > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserialize(RexNodeJsonDeserializer.java:146) > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserialize(RexNodeJsonDeserializer.java:128) > at > org.apache.flink.table.planner.plan.nodes.exec.serde.RexNodeJsonDeserializer.deserialize(RexNodeJsonDeserializer.java:115) > {code} > The root cause is that although ModuleManager can resolve '$UNNEST_ROWS$1', > the output type strategy is "Missing"; as a result, > FunctionCatalogOperatorTable#convertToBridgingSqlFunction returns empty. > !screenshot-1.png|width=675,height=295! -- This message was sent by Atlassian Jira (v8.20.10#820010)