[
https://issues.apache.org/jira/browse/CALCITE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14314890#comment-14314890
]
Jinfeng Ni commented on CALCITE-593:
------------------------------------
Making Frameworks validator consistent will help solve a problem Drill is
facing (The problem will not happen if the query uses CalcitePrepareImpl).
On the other hand, I'm wondering if SqlValidator by default should expand
identifier, in stead of the opposite. At least one place in Calcite code
assumes to expand identifier,
SqlFunction:290 has the following code:
{code}
// REVIEW jvs 25-Mar-2005: This is, in a sense, expanding
// identifiers, but we ignore shouldExpandIdentifiers()
// because otherwise later validation code will
// choke on the unresolved function.
((SqlBasicCall) call).setOperator(function);
{code}
That seems to always expand identifier. So, if SqlValidatorImpl set the flag to
false, then some validation code might run into problem, especially when there
is UDF with case insensitivity matching for function name resolution.
> SqlValidator in Frameworks did not expand identifier by default, which is
> different if the query goes through JDBC and uses CalcitePrepareImpl.
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-593
> URL: https://issues.apache.org/jira/browse/CALCITE-593
> Project: Calcite
> Issue Type: Bug
> Reporter: Jinfeng Ni
> Assignee: Julian Hyde
>
> Calcite supports two ways to build query plan for a SQL statement. Either
> submit the query through JDBC, which will use CalcitePrepareImpl class, or
> build a customized planner by leveraging the Frameworks/PlannerImpl class.
> However, the SqlValidator created in Frameworks/PlannerImpl uses a different
> setting in terms of identifier expanding, than the setting in the
> SqlValidator in CalcitePrepareImpl. This implies that one same query goes
> through those two SqlValidators would have different validated forms.
> SqlValidator.expandIdentifiers in by default is set to false. But
> CalcitePrepareImpl.prepare() will reset it to true at CalcitePrepareImpl:494:
> {code}
> final SqlValidator validator =
> new CalciteSqlValidator(opTab, catalogReader, typeFactory);
> validator.setIdentifierExpansion(true);
> {code}
> In contrast, the SqlValidator created in Frameworks/PlannerImpl will still
> use the default "false" setting.
> Further, Frameworks does not expose the instance of SqlValidator, so user
> does not have a way to change the setting for the SqlValidator created in
> Frameworks/PlannerImpl.
> To make behaviors consistent, I would like to propose that we make
> Framework's SqlValidator uses the same setting as the one in
> CalcitePrepareImpl.
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
