[jira] [Commented] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753318#comment-16753318
]
Hequn Cheng commented on CALCITE-2801:
--
Hi [~julianhyde] , thanks a lot for the tips. It seems that we can only use
RelBuilder.convert to convert to a new rowtype with the same FieldCount. While,
in order to fix this problem, we have to add a Project with a new rowtype with
different FieldCount. (Probably we should use RelOptUtil.createProject() ?)
I have created a pull request. Would be great if you can take a look. Thank you.
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and
> use it's input as the new input of Union directly. However, the bottom
> Aggregate and it's input may not share the same row type. As Union requires
> all inputs with a same row type, once we remove the bottom Aggregate, an
> exception will be thrown.
> The exception can be reproduced by the following test:
> {code:java}
> @Test public void testPullAggregateThroughUnion() {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(AggregateProjectMergeRule.INSTANCE)
> .addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
> .build();
> final String sql = "select job, deptno from"
> + " (select job, deptno from emp as e1"
> + " group by job, deptno"
> + " union all"
> + " select job, deptno from emp as e2"
> + " group by job, deptno)"
> + " group by job, deptno";
> sql(sql).with(program).check();
> }
> {code}
> {code:java}
> java.lang.IllegalArgumentException: Cannot compute compatible row type for
> arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
> RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
> TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
> SLACKER)
> at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
> at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
> at
> org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
> at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
> {code}
> I see two option to solve the problem:
> - Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
> directly.
> - Add a Project with a same row type to the bottom Aggregate.
> What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752189#comment-16752189
]
Hequn Cheng commented on CALCITE-2801:
--
Hi [~julianhyde] , thanks a lot for the valuable suggestions. I will watch out
for this. We can make sure that the Project only be added if needed in
{{AggregateUnionAggregateRule}}, i.e., union input types are not same when the
bottom aggregate is pulled up. I will also try to check if there are other
rules that will remove the "fixup" Project as it will also cause cycles.
I will give it a try. Thank you very much!
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and
> use it's input as the new input of Union directly. However, the bottom
> Aggregate and it's input may not share the same row type. As Union requires
> all inputs with a same row type, once we remove the bottom Aggregate, an
> exception will be thrown.
> The exception can be reproduced by the following test:
> {code:java}
> @Test public void testPullAggregateThroughUnion() {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(AggregateProjectMergeRule.INSTANCE)
> .addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
> .build();
> final String sql = "select job, deptno from"
> + " (select job, deptno from emp as e1"
> + " group by job, deptno"
> + " union all"
> + " select job, deptno from emp as e2"
> + " group by job, deptno)"
> + " group by job, deptno";
> sql(sql).with(program).check();
> }
> {code}
> {code:java}
> java.lang.IllegalArgumentException: Cannot compute compatible row type for
> arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
> RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
> TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
> SLACKER)
> at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
> at
> org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
> at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
> at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
> at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
> at
> org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
> at
> org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
> at
> org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
> at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
> {code}
> I see two option to solve the problem:
> - Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
> directly.
> - Add a Project with a same row type to the bottom Aggregate.
> What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
[
https://issues.apache.org/jira/browse/CALCITE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-2801:
-
Description:
In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and use
it's input as the new input of Union directly. However, the bottom Aggregate
and it's input may not share the same row type. As Union requires all inputs
with a same row type, once we remove the bottom Aggregate, an exception will be
thrown.
The exception can be reproduced by the following test:
{code:java}
@Test public void testPullAggregateThroughUnion() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(AggregateProjectMergeRule.INSTANCE)
.addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
.build();
final String sql = "select job, deptno from"
+ " (select job, deptno from emp as e1"
+ " group by job, deptno"
+ " union all"
+ " select job, deptno from emp as e2"
+ " group by job, deptno)"
+ " group by job, deptno";
sql(sql).with(program).check();
}
{code}
{code:java}
java.lang.IllegalArgumentException: Cannot compute compatible row type for
arguments to set op: RecordType(VARCHAR(10) JOB, INTEGER DEPTNO),
RecordType(INTEGER EMPNO, VARCHAR(20) ENAME, VARCHAR(10) JOB, INTEGER MGR,
TIMESTAMP(0) HIREDATE, INTEGER SAL, INTEGER COMM, INTEGER DEPTNO, BOOLEAN
SLACKER)
at org.apache.calcite.rel.core.SetOp.deriveRowType(SetOp.java:111)
at
org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:222)
at
org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2378)
at
org.apache.calcite.tools.RelBuilder$Frame.(RelBuilder.java:2363)
at org.apache.calcite.tools.RelBuilder.push(RelBuilder.java:260)
at org.apache.calcite.tools.RelBuilder.setOp(RelBuilder.java:1559)
at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1579)
at org.apache.calcite.tools.RelBuilder.union(RelBuilder.java:1569)
at
org.apache.calcite.rel.rules.AggregateUnionAggregateRule.onMatch(AggregateUnionAggregateRule.java:130)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:559)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:418)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:255)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:214)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:201)
at
org.apache.calcite.test.RelOptTestBase.checkPlanning(RelOptTestBase.java:206)
at
org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:334)
at
org.apache.calcite.test.RelOptTestBase$Sql.check(RelOptTestBase.java:317)
at org.apache.calcite.test.RelOptRulesTest.testPullAggregateThroughUnion
{code}
I see two option to solve the problem:
- Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
directly.
- Add a Project with a same row type to the bottom Aggregate.
What do you guys think? Thanks a lot.
was:
In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and use
it's input as the new input of Union directly. However, the bottom Aggregate
and it's input may not share the same row type. As Union requires all inputs
with a same row type, once we remove the bottom Aggregate, an exception will be
thrown.
The exception can be reproduced by the following test:
{code:java}
@Test public void testPullAggregateThroughUnion() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(AggregateProjectMergeRule.INSTANCE)
.addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
.build();
final String sql = "select job, deptno from"
+ " (select job, deptno from emp as e1"
+ " group by job, deptno"
+ " union all"
+ " select job, deptno from emp as e2"
+ " group by job, deptno)"
+ " group by job, deptno";
sql(sql).with(program).check();
}
{code}
I see two option to solve the problem:
- Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
directly.
- Add a Project with a same row type to the bottom Aggregate.
What do you guys think? Thanks a lot.
> Check input type in AggregateUnionAggregateRule when remove the bottom
> Aggregate
>
>
> Key: CALCITE-2801
> URL: https://issues.apache.org/jira/browse/CALCITE-2801
> Project: Calcite
>
[jira] [Created] (CALCITE-2801) Check input type in AggregateUnionAggregateRule when remove the bottom Aggregate
Hequn Cheng created CALCITE-2801:
Summary: Check input type in AggregateUnionAggregateRule when
remove the bottom Aggregate
Key: CALCITE-2801
URL: https://issues.apache.org/jira/browse/CALCITE-2801
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Hequn Cheng
Assignee: Hequn Cheng
In {{AggregateUnionAggregateRule}}, we may remove the bottom Aggregate and use
it's input as the new input of Union directly. However, the bottom Aggregate
and it's input may not share the same row type. As Union requires all inputs
with a same row type, once we remove the bottom Aggregate, an exception will be
thrown.
The exception can be reproduced by the following test:
{code:java}
@Test public void testPullAggregateThroughUnion() {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(AggregateProjectMergeRule.INSTANCE)
.addRuleInstance(AggregateUnionAggregateRule.INSTANCE)
.build();
final String sql = "select job, deptno from"
+ " (select job, deptno from emp as e1"
+ " group by job, deptno"
+ " union all"
+ " select job, deptno from emp as e2"
+ " group by job, deptno)"
+ " group by job, deptno";
sql(sql).with(program).check();
}
{code}
I see two option to solve the problem:
- Check the input type in {{AggregateUnionAggregateRule}} and exit the rule
directly.
- Add a Project with a same row type to the bottom Aggregate.
What do you guys think? Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2683) ProjectMergeRule should not be performed when Nondeterministic udf has been referenced more than once
[
https://issues.apache.org/jira/browse/CALCITE-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-2683:
-
Description:
Currently, there are some merge rules for project, such as {{CalcMergeRule}},
{{ProjectMergeRule}}, and {{ProjectCalcMergeRule}}. I found that these merge
rules should not be performed when Nondeterministic expression of the bottom
project has been referenced more than once by the top project. Take the
following test as an example:
{code:java}
@Test public void testProjectMergeCalcMergeWithNonDeterministic() throws
Exception {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(FilterProjectTransposeRule.INSTANCE)
.addRuleInstance(ProjectMergeRule.INSTANCE)
.build();
checkPlanning(program,
"select name, a as a1, a as a2 from (\n"
+ " select *, rand() as a\n"
+ " from dept)\n"
+ "where deptno = 10\n");
}
{code}
The first select generates `a` from `rand()` and the second select generate
`a1` and `a2` from `a`. From the SQL, `a1` should equal to `a2`.
Let's take a look at the result plan:
{code:java}
LogicalProject(NAME=[$1], A1=[RAND()], A2=[RAND()])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
In the plan, {color:#FF}a1{color} may not equal to {color:#FF}a2{color}
due to the projects merge which is against the SQL(a1 equals to a2).
One option to solve the problem is to disable these merge rules in such cases,
so that the result plan will be:
{code:java}
LogicalProject(NAME=[$1], A1=[$2], A2=[$2])
LogicalProject(DEPTNO=[$0], NAME=[$1], A=[RAND()])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
Any suggestions are greatly appreciated.
was:
Currently, there are some merge rules for project, such as {{CalcMergeRule}},
{{ProjectMergeRule}}, and {{ProjectCalcMergeRule}}. I found that these merge
rules should not be performed when Nondeterministic expression of the bottom
project has been referenced more than once by the top project. Take the
following test as an example:
{code:java}
@Test public void testProjectMergeCalcMergeWithNonDeterministic() throws
Exception {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(FilterProjectTransposeRule.INSTANCE)
.addRuleInstance(ProjectMergeRule.INSTANCE)
.build();
checkPlanning(program,
"select name, a as a1, a as a2 from (\n"
+ " select *, rand() as a\n"
+ " from dept)\n"
+ "where deptno = 10\n");
}
{code}
The result plan is
{code:java}
LogicalProject(NAME=[$1], {color:red}A1{color}=[RAND()],
{color:red}A2{color}=[RAND()])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
In the plan, {color:red}A1{color} may not equal to {color:red}A2{color} since
the two projects are merged which is against the SQL.
One option to solve the problem is to disable these merge rules in such cases.
What do you guys think? Any suggestions are greatly appreciated.
> ProjectMergeRule should not be performed when Nondeterministic udf has been
> referenced more than once
> -
>
> Key: CALCITE-2683
> URL: https://issues.apache.org/jira/browse/CALCITE-2683
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> Currently, there are some merge rules for project, such as {{CalcMergeRule}},
> {{ProjectMergeRule}}, and {{ProjectCalcMergeRule}}. I found that these merge
> rules should not be performed when Nondeterministic expression of the bottom
> project has been referenced more than once by the top project. Take the
> following test as an example:
> {code:java}
> @Test public void testProjectMergeCalcMergeWithNonDeterministic() throws
> Exception {
> HepProgram program = new HepProgramBuilder()
> .addRuleInstance(FilterProjectTransposeRule.INSTANCE)
> .addRuleInstance(ProjectMergeRule.INSTANCE)
> .build();
> checkPlanning(program,
> "select name, a as a1, a as a2 from (\n"
> + " select *, rand() as a\n"
> + " from dept)\n"
> + "where deptno = 10\n");
> }
> {code}
> The first select generates `a` from `rand()` and the second select generate
> `a1` and `a2` from `a`. From the SQL, `a1` should equal to `a2`.
> Let's take a look at the result plan:
> {code:java}
> LogicalProject(NAME=[$1], A1=[RAND()], A2=[RAND()])
> LogicalFilter(condition=[=($0, 10)
[jira] [Created] (CALCITE-2683) ProjectMergeRule should not be performed when Nondeterministic udf has been referenced more than once
Hequn Cheng created CALCITE-2683:
Summary: ProjectMergeRule should not be performed when
Nondeterministic udf has been referenced more than once
Key: CALCITE-2683
URL: https://issues.apache.org/jira/browse/CALCITE-2683
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Hequn Cheng
Assignee: Hequn Cheng
Currently, there are some merge rules for project, such as {{CalcMergeRule}},
{{ProjectMergeRule}}, and {{ProjectCalcMergeRule}}. I found that these merge
rules should not be performed when Nondeterministic expression of the bottom
project has been referenced more than once by the top project. Take the
following test as an example:
{code:java}
@Test public void testProjectMergeCalcMergeWithNonDeterministic() throws
Exception {
HepProgram program = new HepProgramBuilder()
.addRuleInstance(FilterProjectTransposeRule.INSTANCE)
.addRuleInstance(ProjectMergeRule.INSTANCE)
.build();
checkPlanning(program,
"select name, a as a1, a as a2 from (\n"
+ " select *, rand() as a\n"
+ " from dept)\n"
+ "where deptno = 10\n");
}
{code}
The result plan is
{code:java}
LogicalProject(NAME=[$1], {color:red}A1{color}=[RAND()],
{color:red}A2{color}=[RAND()])
LogicalFilter(condition=[=($0, 10)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
{code}
In the plan, {color:red}A1{color} may not equal to {color:red}A2{color} since
the two projects are merged which is against the SQL.
One option to solve the problem is to disable these merge rules in such cases.
What do you guys think? Any suggestions are greatly appreciated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-2311) case when returns redundant white space
[
https://issues.apache.org/jira/browse/CALCITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng closed CALCITE-2311.
Resolution: Fixed
This was fixed by
[CALCITE-2321|https://issues.apache.org/jira/browse/CALCITE-2321].
> case when returns redundant white space
> ---
>
> Key: CALCITE-2311
> URL: https://issues.apache.org/jira/browse/CALCITE-2311
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> If the case-when expression has two branches which returns string
> literal,redundant white space will append to the short string literal after
> the ReduceExpressionsRule. For example:
> {code:java}
> case when id>0 then 'a' else 'abc' end{code}
> will actually be convert to
> {code:java}
> case when id>0 then 'a ' else 'abc' end{code}
>
> The reason is that the type of 'a' is CHAR(1),but CHAR(3) for 'abc',so the
> return type of the case-when is CHAR(3). The RexBuilder#ensureType() method
> append a cast convertion for 'a' to cast it to CHAR(3) type.The
> ReduceExpressionsRule execute the cast convertion which fill two whilte space
> to 'a'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504481#comment-16504481
]
Hequn Cheng commented on CALCITE-2321:
--
[~julianhyde] Hi, It would be great if you can take a look at the updates.
Thanks a lot.
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493097#comment-16493097
]
Hequn Cheng commented on CALCITE-2321:
--
Hi [~julianhyde], thanks for your review and valuable suggestions. I have
addressed all your comments except for the second one, which I still put
{{sqlConformance}} as a constructor parameter to the {{JavaTypeFactoryImpl}}.
Sorry that haven't find a better way. It would be great if you can take a look
at the updates.
Best, Hequn.
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490585#comment-16490585
]
Hequn Cheng commented on CALCITE-2321:
--
Hi, Committers, PR for the issue: https://github.com/apache/calcite/pull/699
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16487466#comment-16487466
]
Hequn Cheng commented on CALCITE-2321:
--
Thanks for your advice. I will give it a try according to your suggestions.
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483878#comment-16483878
]
Hequn Cheng edited comment on CALCITE-2321 at 5/22/18 2:23 PM:
---
Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they
all return the value without blank-padded. Also, it seems that there is no way
to turn blank-padded on. I found some clear descriptions in mysql reference
manual: "If all types are character string (CHAR or VARCHAR), the result is
VARCHAR with maximum length determined by the longest character length of the
operands". Maybe we should make
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return
true by default?
As for creating a type system, other system can create their own type system by
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried
to set it via dialect, but find it is hard to make use of it in
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is
used during rel to sql conversion.
Thanks, Hequn
was (Author: hequn8128):
Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they
all return the value without blank-padded. Also, it seems that there is no way
to turn blank-padded on. Maybe we should make
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return
true by default?
As for creating a type system, other system can create their own type system by
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried
to set it via dialect, but find it is hard to make use of it in
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is
used during rel to sql conversion.
Thanks, Hequn
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16483878#comment-16483878
]
Hequn Cheng commented on CALCITE-2321:
--
Hi [~julianhyde], thanks for your reply. I test Oracle/SqlServer/Mysql and they
all return the value without blank-padded. Also, it seems that there is no way
to turn blank-padded on. Maybe we should make
{{shouldRaggedFixedLengthValueUnionBeVariable()}} configurable meanwhile return
true by default?
As for creating a type system, other system can create their own type system by
extending {{RelDataTypeSystemImpl}}, and this may not be a hard work. I tried
to set it via dialect, but find it is hard to make use of it in
{{SqlTypeFactoryImpl}} during sql to rel conversion. It seems that dialect is
used during rel to sql conversion.
Thanks, Hequn
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2321) Support ragged fixed length value union be variable
[
https://issues.apache.org/jira/browse/CALCITE-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-2321:
-
Description:
The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
{{SqlTypeFactoryImpl}} always return false now. It is good to make it
configurable since some system may need the function to return true to provide
pragmatic behavior. For example, for the sql: case 1 when 1 then 'a' when 2
then 'bcd' end, we need the return value to be 'a' instead of 'a ' of CHAR(3).
I see one option to solve this issue: Add {{boolean
shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
external system can override to configure the value.
Any suggestions are welcomed. Thanks a lot.
was:
The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
{{SqlTypeFactoryImpl}} always return false now. It is good to make it
configurable since some system may need the function to return true to provide
pragmatic behavior.
I see one option to solve this issue: Add {{boolean
shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
external system can override to configure the value.
Any suggestions are welcomed. Thanks a lot.
> Support ragged fixed length value union be variable
> ---
>
> Key: CALCITE-2321
> URL: https://issues.apache.org/jira/browse/CALCITE-2321
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Hequn Cheng
>Assignee: Hequn Cheng
>Priority: Major
>
> The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
> {{SqlTypeFactoryImpl}} always return false now. It is good to make it
> configurable since some system may need the function to return true to
> provide pragmatic behavior. For example, for the sql: case 1 when 1 then 'a'
> when 2 then 'bcd' end, we need the return value to be 'a' instead of 'a ' of
> CHAR(3).
> I see one option to solve this issue: Add {{boolean
> shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
> external system can override to configure the value.
> Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2321) Support ragged fixed length value union be variable
Hequn Cheng created CALCITE-2321:
Summary: Support ragged fixed length value union be variable
Key: CALCITE-2321
URL: https://issues.apache.org/jira/browse/CALCITE-2321
Project: Calcite
Issue Type: New Feature
Components: core
Reporter: Hequn Cheng
Assignee: Hequn Cheng
The {{shouldRaggedFixedLengthValueUnionBeVariable()}} function in
{{SqlTypeFactoryImpl}} always return false now. It is good to make it
configurable since some system may need the function to return true to provide
pragmatic behavior.
I see one option to solve this issue: Add {{boolean
shouldRaggedFixedLengthValueUnionBeVariable()}} in {{RelDataTypeSystem}}, so
external system can override to configure the value.
Any suggestions are welcomed. Thanks a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385565#comment-16385565
]
Hequn Cheng commented on CALCITE-2198:
--
OK, Thanks for your reply and suggestions. And would you please give me the
contributor permissions?
User profile of my jira:
{code:java}
Username: hequn8128
Full name: Hequn Cheng
Email: chenghequn at gmail dot com{code}
Thanks, Hequn
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383159#comment-16383159
]
Hequn Cheng commented on CALCITE-2198:
--
Hi, [~julianhyde]
Thanks very much for your reply. It make sense to require a value immutable and
implements Comparable for RexLiteral, but i think Calcite should also provide
utils to convert the type of a value to comply with
RexLiteral.valueMatchesType(), so that users don't have to convert by
themselves. What do you think?
PS: Whenever I create an issue, it will assign to you automatically. How can I
assign it to myself? Thanks.
Best, Hequn
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
[
https://issues.apache.org/jira/browse/CALCITE-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-2198:
-
Description:
Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
{{ClassCastException}} when value type is {{byte[]}}:
{code:java}
java.lang.ClassCastException: [B cannot be cast to
org.apache.calcite.avatica.util.ByteString
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
at
org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
The exception can be reproduced by the following test case(in
RexProgramTest.testSimplifyCastLiteral()):
{code:java}
literals.add((RexLiteral)
rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
To avoid this exception we have to add support for type of {{byte[]}}. One
choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
was:
Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
{{ClassCastException}} when value type is {{byte[]}}:
{code:java}
java.lang.ClassCastException: [B cannot be cast to
org.apache.calcite.avatica.util.ByteString
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1271)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1251){code}
To avoid this exception we have to add support for type of {{byte[]}}. One
choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
> ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
> --
>
> Key: CALCITE-2198
> URL: https://issues.apache.org/jira/browse/CALCITE-2198
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>Priority: Major
>
> Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
> {{ClassCastException}} when value type is {{byte[]}}:
> {code:java}
> java.lang.ClassCastException: [B cannot be cast to
> org.apache.calcite.avatica.util.ByteString
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1336)
> at
> org.apache.calcite.test.RexProgramTest.testSimplifyCastLiteral(RexProgramTest.java:1567){code}
> The exception can be reproduced by the following test case(in
> RexProgramTest.testSimplifyCastLiteral()):
> {code:java}
> literals.add((RexLiteral)
> rexBuilder.makeLiteral(new byte[] {1, 2, -34, 0, -128},
> typeFactory.createSqlType(SqlTypeName.BINARY, 5), false));{code}
> To avoid this exception we have to add support for type of {{byte[]}}. One
> choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2198) ClassCastException in RexBuilder when makeLiteral for BINARY and VARBINARY
Hequn Cheng created CALCITE-2198:
Summary: ClassCastException in RexBuilder when makeLiteral for
BINARY and VARBINARY
Key: CALCITE-2198
URL: https://issues.apache.org/jira/browse/CALCITE-2198
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Hequn Cheng
Assignee: Julian Hyde
Currently, makeLiteral for {{BINARY}} and {{VARBINARY}} will throw
{{ClassCastException}} when value type is {{byte[]}}:
{code:java}
java.lang.ClassCastException: [B cannot be cast to
org.apache.calcite.avatica.util.ByteString
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1271)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1251){code}
To avoid this exception we have to add support for type of {{byte[]}}. One
choice is to convert {{byte[]}} to {{ByteString}} in {{RexBuilder.clean()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CALCITE-1979) Case When result type precision problem
[
https://issues.apache.org/jira/browse/CALCITE-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng closed CALCITE-1979.
Resolution: Won't Do
> Case When result type precision problem
> ---
>
> Key: CALCITE-1979
> URL: https://issues.apache.org/jira/browse/CALCITE-1979
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>
> Considering such query:
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
> This makes "ARRIVAL" to "ARRIVAL " with two spaces behind. But what users
> want is just "ARRIVAL".
> Also users may write the following query(with one space behind ARRIVAL):
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will also be {{BasicSqlType}} with precision
> 9, which makes no differences to the first query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1979) Case When result type precision problem
[
https://issues.apache.org/jira/browse/CALCITE-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16300882#comment-16300882
]
Hequn Cheng commented on CALCITE-1979:
--
Cast char to varchar will solve this problem.
> Case When result type precision problem
> ---
>
> Key: CALCITE-1979
> URL: https://issues.apache.org/jira/browse/CALCITE-1979
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>
> Considering such query:
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
> This makes "ARRIVAL" to "ARRIVAL " with two spaces behind. But what users
> want is just "ARRIVAL".
> Also users may write the following query(with one space behind ARRIVAL):
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will also be {{BasicSqlType}} with precision
> 9, which makes no differences to the first query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1979) Case When result type precision problem
[
https://issues.apache.org/jira/browse/CALCITE-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-1979:
-
Description:
Considering such query:
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b FROM
sourceTable"
{quote}
The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
This makes "ARRIVAL" to "ARRIVAL " with two spaces behind. But what users
want is just "ARRIVAL".
Also users may write the following query(with one space behind ARRIVAL):
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
FROM sourceTable"
{quote}
The result type of {{case when}} will also be {{BasicSqlType}} with precision
9, which makes no differences to the first query.
was:
Considering such query:
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b FROM
sourceTable"
{quote}
The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
This makes "ARRIVAL" to "ARRIVAL " with two spaces behind.
Also users may write the following query(with one space behind ARRIVAL):
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
FROM sourceTable"
{quote}
The result type of {{case when}} will also be {{BasicSqlType}} with precision 9.
These may not what the users want. And I am wondering if there is a way to
solve this problem?
> Case When result type precision problem
> ---
>
> Key: CALCITE-1979
> URL: https://issues.apache.org/jira/browse/CALCITE-1979
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>
> Considering such query:
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
> This makes "ARRIVAL" to "ARRIVAL " with two spaces behind. But what users
> want is just "ARRIVAL".
> Also users may write the following query(with one space behind ARRIVAL):
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will also be {{BasicSqlType}} with precision
> 9, which makes no differences to the first query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CALCITE-1979) Case When result type precision problem
[
https://issues.apache.org/jira/browse/CALCITE-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hequn Cheng updated CALCITE-1979:
-
Description:
Considering such query:
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b FROM
sourceTable"
{quote}
The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
This makes "ARRIVAL" to "ARRIVAL " with two spaces behind.
Also users may write the following query(with one space behind ARRIVAL):
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
FROM sourceTable"
{quote}
The result type of {{case when}} will also be {{BasicSqlType}} with precision 9.
These may not what the users want. And I am wondering if there is a way to
solve this problem?
was:
Considering such query:
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b FROM
sourceTable"
{quote}
The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
This makes "ARRIVAL" to "ARRIVAL " with two spaces behind.
Also users may write the following query(with one space behind ARRIVAL):
"SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
FROM sourceTable"
{quote}
The result type of {{case when}} will also be {{BasicSqlType}} with precision 9.
These may not what the users want. And I am wondering if there is a way to
solve this problem?
> Case When result type precision problem
> ---
>
> Key: CALCITE-1979
> URL: https://issues.apache.org/jira/browse/CALCITE-1979
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Hequn Cheng
>Assignee: Julian Hyde
>
> Considering such query:
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
> This makes "ARRIVAL" to "ARRIVAL " with two spaces behind.
> Also users may write the following query(with one space behind ARRIVAL):
> {quote}
> "SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
> FROM sourceTable"
> {quote}
> The result type of {{case when}} will also be {{BasicSqlType}} with precision
> 9.
> These may not what the users want. And I am wondering if there is a way to
> solve this problem?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CALCITE-1979) Case When result type precision problem
Hequn Cheng created CALCITE-1979:
Summary: Case When result type precision problem
Key: CALCITE-1979
URL: https://issues.apache.org/jira/browse/CALCITE-1979
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Hequn Cheng
Assignee: Julian Hyde
Considering such query:
{quote}
"SELECT a, case when c = 'Hi' then 'ARRIVAL' else 'DEPARTURE' end as cc, b FROM
sourceTable"
{quote}
The result type of {{case when}} will be {{BasicSqlType}} with precision 9.
This makes "ARRIVAL" to "ARRIVAL " with two spaces behind.
Also users may write the following query(with one space behind ARRIVAL):
"SELECT a, case when c = 'Hi' then 'ARRIVAL ' else 'DEPARTURE' end as cc, b
FROM sourceTable"
{quote}
The result type of {{case when}} will also be {{BasicSqlType}} with precision 9.
These may not what the users want. And I am wondering if there is a way to
solve this problem?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
