[jira] [Commented] (CALCITE-2224) WITHIN GROUP clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416558#comment-16416558
]
Julian Hyde commented on CALCITE-2224:
--
I don't plan to work on this. I filed it just as a placeholder for future
discussions. If you would like to work on it (or just some of it) that would be
awesome.
I imagine we would add a {{List}} field to
{{AggregateCall}}, which would be the empty list most of the time.
> WITHIN GROUP clause for aggregate functions
> ---
>
> Key: CALCITE-2224
> URL: https://issues.apache.org/jira/browse/CALCITE-2224
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The {{WITHIN GROUP}} clause lets aggregate functions operate on a sorted list
> of rows, rather than the usual unsorted collection. Order only matters for a
> few aggregate functions, but we should allow it for all.
> Other analytic functions where {{WITHIN GROUP}} would have an effect:
> {{RANK}}, {{PERCENT_RANK}}, {{FIRST_VALUE}}, {{LAST_VALUE}},
> {{PERCENTILE_CONT}}, {{PERCENTILE_DISC}}.
> {{LISTAGG(value [, separator])}} is an [Oracle
> function|https://docs.oracle.com/cloud/latest/db112/SQLRF/functions089.htm#SQLRF30030]
> that concatenates strings. E.g.
> {code:java}
> SELECT LISTAGG(last_name, '; ')
> WITHIN GROUP (ORDER BY hire_date, last_name)
> FROM Emp
> GROUP BY deptno{code}
> {{STRING_AGG(value [, separator])}} is a [Microsoft SQL Server function|]
> that does something similar.
> {{GROUP_CONCAT(value [, separator] [ORDER BY expr [, expr]...)}} is the
> [MySQL|https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat]
> equivalent to {{LISTAGG}}. Note the optional {{ORDER BY}} clause within the
> parentheses.
> {{COLLECT(value)}} is a SQL standard aggregate function that creates
> multisets. Oracle added a non-standard {{ORDER BY}} clause within the
> parentheses.
> In my opinion, {{WITHIN GROUP}} should always be optional. {{LISTAGG}}
> without {{WITHIN GROUP}} would produce non-deterministic output (which is
> OK); other aggregate functions such as {{MIN}} and {{SUM}} would just ignore
> {{WITHIN GROUP}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2223) ProjectMergeRule is infinitely matched when is applied after ProjectReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416553#comment-16416553
]
zhen wang commented on CALCITE-2223:
I suspect this is connected to CALCITE-1862, taking a look.
> ProjectMergeRule is infinitely matched when is applied after
> ProjectReduceExpressionsRule
> -
>
> Key: CALCITE-2223
> URL: https://issues.apache.org/jira/browse/CALCITE-2223
> Project: Calcite
> Issue Type: Bug
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Critical
>
> For queries like this:
> {code:sql}
> select t1.f from (select cast(f as int) f, f from (select cast(f as int) f
> from (values('1')) t(f))) as t1
> {code}
> OOM is thrown when {{ProjectMergeRule}} is applied before applying
> {{ProjectReduceExpressionsRule}} in VolcanoPlanner.
> A simple test to reproduce this issue (in {{RelOptRulesTest}}):
> {code:java}
> @Test public void testOomProjectMergeRule() {
> RelBuilder relBuilder =
> RelBuilder.create(RelBuilderTest.config().build());
> RelNode relNode = relBuilder
> .values(new String[]{"f"}, "1")
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f"))
> .project(
> relBuilder.alias(
> relBuilder.cast(relBuilder.field(0), SqlTypeName.INTEGER),
> "f0"),
> relBuilder.alias(relBuilder.field(0), "f"))
> .project(
> relBuilder.alias(relBuilder.field(0), "f"))
> .build();
> RelOptPlanner planner = relNode.getCluster().getPlanner();
> RuleSet ruleSet =
> RuleSets.ofList(
> ReduceExpressionsRule.PROJECT_INSTANCE,
> new ProjectMergeRuleWithLongerName(),
> EnumerableRules.ENUMERABLE_PROJECT_RULE,
> EnumerableRules.ENUMERABLE_VALUES_RULE);
> Program program = Programs.of(ruleSet);
> RelTraitSet toTraits =
> relNode.getCluster().traitSet()
> .replace(0, EnumerableConvention.INSTANCE);
> RelNode output = program.run(planner, relNode, toTraits,
> ImmutableList.of(),
> ImmutableList.of());
> // check for output
> }
> /**
>* ProjectMergeRule inheritor which has
>* class name greater than ProjectReduceExpressionsRule class name
> (String.compareTo()).
>*
>* It is needed for RuleQueue.popMatch() method
>* to apply this rule before ProjectReduceExpressionsRule.
>*/
> private static class ProjectMergeRuleWithLongerName extends
> ProjectMergeRule {
> public ProjectMergeRuleWithLongerName() {
> super(true, RelFactories.LOGICAL_BUILDER);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2224) WITHIN GROUP clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416503#comment-16416503
]
Shuyi Chen commented on CALCITE-2224:
-
Are you planning to work on this, [~julianhyde]? I can help otherwise.
> WITHIN GROUP clause for aggregate functions
> ---
>
> Key: CALCITE-2224
> URL: https://issues.apache.org/jira/browse/CALCITE-2224
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The {{WITHIN GROUP}} clause lets aggregate functions operate on a sorted list
> of rows, rather than the usual unsorted collection. Order only matters for a
> few aggregate functions, but we should allow it for all.
> Other analytic functions where {{WITHIN GROUP}} would have an effect:
> {{RANK}}, {{PERCENT_RANK}}, {{FIRST_VALUE}}, {{LAST_VALUE}},
> {{PERCENTILE_CONT}}, {{PERCENTILE_DISC}}.
> {{LISTAGG(value [, separator])}} is an [Oracle
> function|https://docs.oracle.com/cloud/latest/db112/SQLRF/functions089.htm#SQLRF30030]
> that concatenates strings. E.g.
> {code:java}
> SELECT LISTAGG(last_name, '; ')
> WITHIN GROUP (ORDER BY hire_date, last_name)
> FROM Emp
> GROUP BY deptno{code}
> {{STRING_AGG(value [, separator])}} is a [Microsoft SQL Server function|]
> that does something similar.
> {{GROUP_CONCAT(value [, separator] [ORDER BY expr [, expr]...)}} is the
> [MySQL|https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat]
> equivalent to {{LISTAGG}}. Note the optional {{ORDER BY}} clause within the
> parentheses.
> {{COLLECT(value)}} is a SQL standard aggregate function that creates
> multisets. Oracle added a non-standard {{ORDER BY}} clause within the
> parentheses.
> In my opinion, {{WITHIN GROUP}} should always be optional. {{LISTAGG}}
> without {{WITHIN GROUP}} would produce non-deterministic output (which is
> OK); other aggregate functions such as {{MIN}} and {{SUM}} would just ignore
> {{WITHIN GROUP}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2224) WITHIN GROUP clause for aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416178#comment-16416178
]
Julian Hyde commented on CALCITE-2224:
--
This is what SQL-2014 says:
* hypothetical set functions ({{RANK}}, {{DENSE_RANK}}, {{PERCENT_RANK}},
{{CUME_DIST}}) and inverse distribution functions ({{PERCENTILE_CONT}},
{{PERCENTILE_DISC}}) can have a {{WITHIN GROUP}} clause, but no others
* there is {{ARRAY_AGG}} which has an {{ORDER BY}} clause inside its
parentheses (similar to Microsoft's {{STRING_AGG}}, Oracle's {{LISTAGG}} and
MySQL's {{GROUP_CONCAT}}, but returning an array)
> WITHIN GROUP clause for aggregate functions
> ---
>
> Key: CALCITE-2224
> URL: https://issues.apache.org/jira/browse/CALCITE-2224
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> The {{WITHIN GROUP}} clause lets aggregate functions operate on a sorted list
> of rows, rather than the usual unsorted collection. Order only matters for a
> few aggregate functions, but we should allow it for all.
> Other analytic functions where {{WITHIN GROUP}} would have an effect:
> {{RANK}}, {{PERCENT_RANK}}, {{FIRST_VALUE}}, {{LAST_VALUE}},
> {{PERCENTILE_CONT}}, {{PERCENTILE_DISC}}.
> {{LISTAGG(value [, separator])}} is an [Oracle
> function|https://docs.oracle.com/cloud/latest/db112/SQLRF/functions089.htm#SQLRF30030]
> that concatenates strings. E.g.
> {code:java}
> SELECT LISTAGG(last_name, '; ')
> WITHIN GROUP (ORDER BY hire_date, last_name)
> FROM Emp
> GROUP BY deptno{code}
> {{STRING_AGG(value [, separator])}} is a [Microsoft SQL Server function|]
> that does something similar.
> {{GROUP_CONCAT(value [, separator] [ORDER BY expr [, expr]...)}} is the
> [MySQL|https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat]
> equivalent to {{LISTAGG}}. Note the optional {{ORDER BY}} clause within the
> parentheses.
> {{COLLECT(value)}} is a SQL standard aggregate function that creates
> multisets. Oracle added a non-standard {{ORDER BY}} clause within the
> parentheses.
> In my opinion, {{WITHIN GROUP}} should always be optional. {{LISTAGG}}
> without {{WITHIN GROUP}} would produce non-deterministic output (which is
> OK); other aggregate functions such as {{MIN}} and {{SUM}} would just ignore
> {{WITHIN GROUP}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2224) WITHIN GROUP clause for aggregate functions
Julian Hyde created CALCITE-2224:
Summary: WITHIN GROUP clause for aggregate functions
Key: CALCITE-2224
URL: https://issues.apache.org/jira/browse/CALCITE-2224
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde
The {{WITHIN GROUP}} clause lets aggregate functions operate on a sorted list
of rows, rather than the usual unsorted collection. Order only matters for a
few aggregate functions, but we should allow it for all.
Other analytic functions where {{WITHIN GROUP}} would have an effect: {{RANK}},
{{PERCENT_RANK}}, {{FIRST_VALUE}}, {{LAST_VALUE}}, {{PERCENTILE_CONT}},
{{PERCENTILE_DISC}}.
{{LISTAGG(value [, separator])}} is an [Oracle
function|https://docs.oracle.com/cloud/latest/db112/SQLRF/functions089.htm#SQLRF30030]
that concatenates strings. E.g.
{code:java}
SELECT LISTAGG(last_name, '; ')
WITHIN GROUP (ORDER BY hire_date, last_name)
FROM Emp
GROUP BY deptno{code}
{{STRING_AGG(value [, separator])}} is a [Microsoft SQL Server function|] that
does something similar.
{{GROUP_CONCAT(value [, separator] [ORDER BY expr [, expr]...)}} is the
[MySQL|https://dev.mysql.com/doc/refman/5.7/en/group-by-functions.html#function_group-concat]
equivalent to {{LISTAGG}}. Note the optional {{ORDER BY}} clause within the
parentheses.
{{COLLECT(value)}} is a SQL standard aggregate function that creates multisets.
Oracle added a non-standard {{ORDER BY}} clause within the parentheses.
In my opinion, {{WITHIN GROUP}} should always be optional. {{LISTAGG}} without
{{WITHIN GROUP}} would produce non-deterministic output (which is OK); other
aggregate functions such as {{MIN}} and {{SUM}} would just ignore {{WITHIN
GROUP}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-878) Allow ORDER BY within COLLECT (an Oracle extension)
[
https://issues.apache.org/jira/browse/CALCITE-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16416068#comment-16416068
]
Julian Hyde commented on CALCITE-878:
-
Since {{ORDER BY}} within {{COLLECT}} is an Oracle-specific extension it would
make more sense to support {{WITHIN GROUP}}, as follows:
{code}SELECT deptno, COLLECT(emp_type(ename, sal)) WITHIN GROUP (ORDER BY sal
DESC) emps
FROM emp
GROUP BY deptno{code}
> Allow ORDER BY within COLLECT (an Oracle extension)
> ---
>
> Key: CALCITE-878
> URL: https://issues.apache.org/jira/browse/CALCITE-878
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Oracle allows ORDER BY within the COLLECT aggregate function, e.g.
> {code}SELECT deptno, COLLECT(emp_type(ename, sal) ORDER BY sal DESC) emps
> FROM emp
> GROUP BY deptno{code}
> This is an Oracle-specific extension to SQL:2011 but nevertheless useful and
> worth considering.
> Note that Calcite already supports DISTINCT within COLLECT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2205) One more Infinite loop for JoinPushTransitivePredicatesRule
[
https://issues.apache.org/jira/browse/CALCITE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415893#comment-16415893
]
Julian Hyde commented on CALCITE-2205:
--
[~vitalii], I changed the subject to something I thought it was more
descriptive. I saw you just changed it back.
> One more Infinite loop for JoinPushTransitivePredicatesRule
> ---
>
> Key: CALCITE-2205
> URL: https://issues.apache.org/jira/browse/CALCITE-2205
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> CALCITE-2200 resolves some cases of infinite loop via stopping of recursion
> in HepPlanner#applyRules, when newVertex is the same as vertex.
> In this jira one more case of infinite loop is described:
> JoinPushTransitivePredicatesRule#onMatch generates new right or left inputs
> via using RelBuilder#filter method on top of LogicalFilter RelNode with the
> same condition.
> In this case a new RelNode shouldn't be created. Possible fix to change logic
> of RelBuilder#filter method.
> TestCase for reproduce:
> {code}
> @Test public void testJoinPushTransitivePredicatesRule2() {
> HepProgramBuilder builder = new HepProgramBuilder();
> builder.addRuleInstance(JoinPushTransitivePredicatesRule.INSTANCE);
> HepProgram build = builder.build();
> HepPlanner hepPlanner = new HepPlanner(build);
> final String sql = "select n1.SAL from EMPNULLABLES_20 n1 where n1.SAL\n"
> + "IN (select n2.SAL from EMPNULLABLES_20 n2 "
> + "where n1.SAL = n2.SAL or n1.SAL = 4)";
> sql(sql)
> .withDecorrelation(true)
> .with(hepPlanner)
> .check();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2201) Allow passing custom RelBuilder into RelDecorrelator and RelStructuredTypeFlattener
[
https://issues.apache.org/jira/browse/CALCITE-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415390#comment-16415390
]
Volodymyr Vysotskyi commented on CALCITE-2201:
--
[~julianhyde], thanks for the review and reworking!
> Allow passing custom RelBuilder into RelDecorrelator and
> RelStructuredTypeFlattener
> ---
>
> Key: CALCITE-2201
> URL: https://issues.apache.org/jira/browse/CALCITE-2201
> Project: Calcite
> Issue Type: Task
>Reporter: Volodymyr Vysotskyi
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> When {{RelDecorrelator.decorrelateQuery()}} method is called,
> {{RelDecorrelator}} instance with {{RelFactories.LOGICAL_BUILDER}} is
> created. We should modify this method to allow usage of custom {{RelBuilder}}.
> Also, {{RelStructuredTypeFlattener}} class should be modified in a similar
> way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2206) Queries with window functions fail when using HSQLDB
[
https://issues.apache.org/jira/browse/CALCITE-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415240#comment-16415240
]
Pavel Gubin commented on CALCITE-2206:
--
Is there anything else that needs to be done to get this merged?
> Queries with window functions fail when using HSQLDB
>
>
> Key: CALCITE-2206
> URL: https://issues.apache.org/jira/browse/CALCITE-2206
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.15.0
>Reporter: Pavel Gubin
>Assignee: Julian Hyde
>Priority: Major
>
> Queries containing window functions fail when using HSQLDB (or any other DB
> that does not support window functions) because optimiser converts them to
> native SQL with window functions which are not supported by HSQLDB. For
> example:
> {code:sql}
> select "store_id", "product_id", sum("unit_sales") unit_sales, row_number()
> over (
> partition by "store_id" order by sum("unit_sales") desc
> ) row_num
> from "sales_fact_1998"
> group by "store_id", "product_id"
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2205) One more Infinite loop for JoinPushTransitivePredicatesRule
[
https://issues.apache.org/jira/browse/CALCITE-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitalii Diravka updated CALCITE-2205:
-
Summary: One more Infinite loop for JoinPushTransitivePredicatesRule (was:
JoinPushTransitivePredicatesRule should not create a Filter on top of an
equivalent Filter)
> One more Infinite loop for JoinPushTransitivePredicatesRule
> ---
>
> Key: CALCITE-2205
> URL: https://issues.apache.org/jira/browse/CALCITE-2205
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0
>Reporter: Vitalii Diravka
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> CALCITE-2200 resolves some cases of infinite loop via stopping of recursion
> in HepPlanner#applyRules, when newVertex is the same as vertex.
> In this jira one more case of infinite loop is described:
> JoinPushTransitivePredicatesRule#onMatch generates new right or left inputs
> via using RelBuilder#filter method on top of LogicalFilter RelNode with the
> same condition.
> In this case a new RelNode shouldn't be created. Possible fix to change logic
> of RelBuilder#filter method.
> TestCase for reproduce:
> {code}
> @Test public void testJoinPushTransitivePredicatesRule2() {
> HepProgramBuilder builder = new HepProgramBuilder();
> builder.addRuleInstance(JoinPushTransitivePredicatesRule.INSTANCE);
> HepProgram build = builder.build();
> HepPlanner hepPlanner = new HepPlanner(build);
> final String sql = "select n1.SAL from EMPNULLABLES_20 n1 where n1.SAL\n"
> + "IN (select n2.SAL from EMPNULLABLES_20 n2 "
> + "where n1.SAL = n2.SAL or n1.SAL = 4)";
> sql(sql)
> .withDecorrelation(true)
> .with(hepPlanner)
> .check();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2220) SqlToRelConverter generates incorrect ordinal while flattening a record-valued field
[
https://issues.apache.org/jira/browse/CALCITE-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415124#comment-16415124
]
Shuyi Chen commented on CALCITE-2220:
-
[~julianhyde] , thanks a lot for reviewing PR. The tests for jdk8 pass. Could
you please help merge it?
Also, could you please help take another look at
[CALCITE-2045|https://issues.apache.org/jira/browse/CALCITE-2045]? Thanks a lot.
> SqlToRelConverter generates incorrect ordinal while flattening a
> record-valued field
>
>
> Key: CALCITE-2220
> URL: https://issues.apache.org/jira/browse/CALCITE-2220
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Shuyi Chen
>Priority: Major
>
> SqlToRelConverter generates wrong ordinal when flattening multiple input
> records during converting to RelNode. Issue can be reproduced as follows:
> {code}
> MockTable deptNestedTable =
> MockTable.create(this, salesSchema, "DEPT_NESTED", false, 4);
> deptNestedTable.addColumn("DEPTNO", f.intType, true);
> deptNestedTable.addColumn("NAME", f.varchar10Type);
> deptNestedTable.addColumn("SKILLRECORD", f.skillRecordType);
> deptNestedTable.addColumn("EMPLOYEES", f.empListType);
> registerTable(deptNestedTable);
> {code}
> Run the following test:
> {code}@Test public void testArrayOfRecord() {
> sql("select employees[1] from dept_nested").ok();
> }{code}
> The following error gets thrown when run:
> {noformat}
> java.lang.AssertionError: type mismatch:
> ref:
> RecordType(INTEGER NOT NULL EMPNO, VARCHAR(10) CHARACTER SET "ISO-8859-1"
> COLLATE "ISO-8859-1$en_US$primary" NOT NULL ENAME, RecordType(VARCHAR(10)
> CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL TYPE,
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL DESC) NOT NULL ARRAY NOT NULL SKILLS) NOT NULL ARRAY NOT NULL
> input:
> VARCHAR(20) CHARACTER SET "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT
> NULL
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:1838)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:125)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:57)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:140)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:57)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:107)
> at
> org.apache.calcite.rex.RexVisitorImpl.visitFieldAccess(RexVisitorImpl.java:98)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:149)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:57)
> at org.apache.calcite.rex.RexFieldAccess.accept(RexFieldAccess.java:81)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:187)
> at org.apache.calcite.rel.core.Project.(Project.java:84)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:65)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:120)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:103)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:127)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1064)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2956)
> at
> org.apache.calcite.plan.RelOptUtil.createProject(RelOptUtil.java:2873)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewriteRel(RelStructuredTypeFlattener.java:477)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener$RewriteRelVisitor.visit(RelStructuredTypeFlattener.java:721)
> at
> org.apache.calcite.sql2rel.RelStructuredTypeFlattener.rewrite(RelStructuredTypeFlattener.java:177)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.flattenTypes(SqlToRelConverter.java:462)
> at
>
