[jira] [Updated] (CALCITE-3318) Preserving CAST of STRING operands in comparison operator
[
https://issues.apache.org/jira/browse/CALCITE-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Soma Mondal updated CALCITE-3318:
-
Description:
We have a REL which has this information
select * from employee where employee_id = cast('12' as float);
but Calcite removes the CAST from the STRING literal('12' in our case).
select * from employee where employee_id = '12';
There are dialects which needs explicit casting in the above case and we need
to maintain the CAST in our dialect.
Calcite removes the cast in SqlImplementor's stripCastFromString() method.
I'm thinking of having the dialect intercept this and decide whether or not to
remove the cast.
I have created a PR [https://github.com/apache/calcite/pull/1437]
was:
We have a REL which has this information
select * from employee where employee_id = cast('12' as float);
but Calcite removes the CAST from the STRING literal('12' in our case).
select * from employee where employee_id = '12';
There are dialects which needs explicit casting in the above case and we need
to maintain the CAST in our dialect.
Calcite removes the cast in SqlImplementor's stripCastFromString() method.
I'm thinking of having the dialect intercept this and decide whether or not to
remove the cast.
> Preserving CAST of STRING operands in comparison operator
> -
>
> Key: CALCITE-3318
> URL: https://issues.apache.org/jira/browse/CALCITE-3318
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Soma Mondal
>Priority: Major
>
> We have a REL which has this information
> select * from employee where employee_id = cast('12' as float);
> but Calcite removes the CAST from the STRING literal('12' in our case).
> select * from employee where employee_id = '12';
> There are dialects which needs explicit casting in the above case and we need
> to maintain the CAST in our dialect.
> Calcite removes the cast in SqlImplementor's stripCastFromString() method.
> I'm thinking of having the dialect intercept this and decide whether or not
> to remove the cast.
>
> I have created a PR [https://github.com/apache/calcite/pull/1437]
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3300) Add a star identifier as operand to "SqlCountAggFunction" if no operands given while in the method "createCall"
[
https://issues.apache.org/jira/browse/CALCITE-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921378#comment-16921378
]
Wang Weidong edited comment on CALCITE-3300 at 9/3/19 12:11 PM:
[~julianhyde]
* "I don't think you should make {{SqlCountAggFunction}} "fix itself"; some
caller might conceivably *really* want zero arguments; the bug is in
{{RelToSqlConverter}} and that is the place I think you should fix."
** It may be better to fix this bug in {{RelToSqlConverter, but the problem is
that we cannot distinguish whether "count" with no arguments means "count star"
or not. With fixing in }}{{SqlCountAggFunction, }}{{"count" with no arguments
only means "count star". How do you think about this? }}{{}}
* Please use {{assertThat}} rather than {{assertEquals}} to {{assertTrue}}
** I've found that there is almost {{assertThat everywhere, but in some
situations, it's obviously more convenient to use }}{{assertEquals or
}}{{assertTrue, why is }}{{assertThat the only alternative? }}{{}}
* Are the other changes to {{RelToSqlConverterTest}} necessary?
** That is because the I need to get SqlNode to check whether there is "count
star" but I did not found any available methods or classes to use.
was (Author: wangweidong):
[~julianhyde]
* "I don't think you should make {{SqlCountAggFunction}} "fix itself"; some
caller might conceivably *really* want zero arguments; the bug is in
{{RelToSqlConverter}} and that is the place I think you should fix."
** It may be better to fix this bug in {{RelToSqlConverter, but the problem is
that we cannot distinguish whether "count" with no arguments means "count star"
or not. With fixing }}{{SqlCountAggFunction in, }}{{"count" with no arguments
only means "count star". How do you think about this? }}{{}}
* Please use {{assertThat}} rather than {{assertEquals}} to {{assertTrue}}
** I've found that there is almost {{assertThat everywhere, but in some
situations, it's obviously more convenient to use }}{{assertEquals or
}}{{assertTrue, why is }}{{assertThat the only alternative? }}{{}}
* Are the other changes to {{RelToSqlConverterTest}} necessary?
** That is because the I need to get SqlNode to check whether there is "count
star" but I did not found any available methods or classes to use.
> Add a star identifier as operand to "SqlCountAggFunction" if no operands
> given while in the method "createCall"
> ---
>
> Key: CALCITE-3300
> URL: https://issues.apache.org/jira/browse/CALCITE-3300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h4. Procedure to reproduce the problem:
> - create table {{~^t^~}}
> - parse query select count(*) from t to SqlNode
> - convert SqlNode to RelNode
> - convert RelNode to SqlNode
> - validate the result SqlNode
> test code is like this
> {code:java}
> // code placeholder
> @Test
> public void testSelectCountAll() throws Exception {
> try (Statement s = parserContext.getStatement()) {
> s.execute("create table if not exists t (i int not null)");
> String sql = "select count(*) from t";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> parserContext.getSqlValidator().validate(sqlNode);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> parserContext.getSqlValidator().validate(sqlNodeNew);
> }
> }
> {code}
> Finally we will get an exception as follow:
> {code:java}
> // code placeholder
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Invalid number of arguments to function 'COUNT'. Was expecting 1
> argumentsorg.apache.calcite.runtime.CalciteContextException: At line 0,
> column 0: Invalid number of arguments to function 'COUNT'. Was expecting 1
> arguments at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:783) at
> org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4753)
> at
>
[jira] [Created] (CALCITE-3318) Preserving CAST of STRING operands in comparison operator
Soma Mondal created CALCITE-3318:
Summary: Preserving CAST of STRING operands in comparison operator
Key: CALCITE-3318
URL: https://issues.apache.org/jira/browse/CALCITE-3318
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.20.0
Reporter: Soma Mondal
We have a REL which has this information
select * from employee where employee_id = cast('12' as float);
but Calcite removes the CAST from the STRING literal('12' in our case).
select * from employee where employee_id = '12';
There are dialects which needs explicit casting in the above case and we need
to maintain the CAST in our dialect.
Calcite removes the cast in SqlImplementor's stripCastFromString() method.
I'm thinking of having the dialect intercept this and decide whether or not to
remove the cast.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3300) Add a star identifier as operand to "SqlCountAggFunction" if no operands given while in the method "createCall"
[
https://issues.apache.org/jira/browse/CALCITE-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921378#comment-16921378
]
Wang Weidong commented on CALCITE-3300:
---
[~julianhyde]
* "I don't think you should make {{SqlCountAggFunction}} "fix itself"; some
caller might conceivably *really* want zero arguments; the bug is in
{{RelToSqlConverter}} and that is the place I think you should fix."
** It may be better to fix this bug in {{RelToSqlConverter, but the problem is
that we cannot distinguish whether "count" with no arguments means "count star"
or not. With fixing }}{{SqlCountAggFunction in, }}{{"count" with no arguments
only means "count star". How do you think about this? }}{{}}
* Please use {{assertThat}} rather than {{assertEquals}} to {{assertTrue}}
** I've found that there is almost {{assertThat everywhere, but in some
situations, it's obviously more convenient to use }}{{assertEquals or
}}{{assertTrue, why is }}{{assertThat the only alternative? }}{{}}
* Are the other changes to {{RelToSqlConverterTest}} necessary?
** That is because the I need to get SqlNode to check whether there is "count
star" but I did not found any available methods or classes to use.
> Add a star identifier as operand to "SqlCountAggFunction" if no operands
> given while in the method "createCall"
> ---
>
> Key: CALCITE-3300
> URL: https://issues.apache.org/jira/browse/CALCITE-3300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h4. Procedure to reproduce the problem:
> - create table {{~^t^~}}
> - parse query select count(*) from t to SqlNode
> - convert SqlNode to RelNode
> - convert RelNode to SqlNode
> - validate the result SqlNode
> test code is like this
> {code:java}
> // code placeholder
> @Test
> public void testSelectCountAll() throws Exception {
> try (Statement s = parserContext.getStatement()) {
> s.execute("create table if not exists t (i int not null)");
> String sql = "select count(*) from t";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> parserContext.getSqlValidator().validate(sqlNode);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> parserContext.getSqlValidator().validate(sqlNodeNew);
> }
> }
> {code}
> Finally we will get an exception as follow:
> {code:java}
> // code placeholder
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Invalid number of arguments to function 'COUNT'. Was expecting 1
> argumentsorg.apache.calcite.runtime.CalciteContextException: At line 0,
> column 0: Invalid number of arguments to function 'COUNT'. Was expecting 1
> arguments at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:783) at
> org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4753)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1699)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:270) at
> org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215) at
> org.apache.calcite.sql.fun.SqlCountAggFunction.deriveType(SqlCountAggFunction.java:83)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5477)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5464)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1629)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1614)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4017)
> at
>
[jira] [Created] (CALCITE-3317) Add public constructor for creating LogicalCalc with RelInput type parameter
Wang Yanlin created CALCITE-3317:
Summary: Add public constructor for creating LogicalCalc with
RelInput type parameter
Key: CALCITE-3317
URL: https://issues.apache.org/jira/browse/CALCITE-3317
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When trying to deserializing a RelNode contains a LogicalCalc node in the
tree, got
{code:java}
java.lang.RuntimeException: java.lang.RuntimeException: class does not have
required constructor, class org.apache.calcite.rel.logical.LogicalCalc(RelInput)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
at
org.apache.calcite.plan.RelWriterTest.testCalc(RelWriterTest.java:688)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.RuntimeException: class does not have required
constructor, class org.apache.calcite.rel.logical.LogicalCalc(RelInput)
at
org.apache.calcite.rel.externalize.RelJson.getConstructor(RelJson.java:114)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:98)
at
org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
at
org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
at
org.apache.calcite.plan.RelWriterTest.lambda$testCalc$9(RelWriterTest.java:693)
at
org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
at
org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
... 25 more
{code}
Need to add a public constructor for creating LogicalCalc with RelInput type
parameter, like this
{code:java}
public LogicalCalc(RelInput input)
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3317) Add public constructor for creating LogicalCalc with RelInput type parameter
[
https://issues.apache.org/jira/browse/CALCITE-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3317:
Labels: pull-request-available (was: )
> Add public constructor for creating LogicalCalc with RelInput type parameter
>
>
> Key: CALCITE-3317
> URL: https://issues.apache.org/jira/browse/CALCITE-3317
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
>
> When trying to deserializing a RelNode contains a LogicalCalc node in the
> tree, got
> {code:java}
> java.lang.RuntimeException: java.lang.RuntimeException: class does not have
> required constructor, class
> org.apache.calcite.rel.logical.LogicalCalc(RelInput)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:181)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:125)
> at org.apache.calcite.tools.Frameworks.withPlanner(Frameworks.java:143)
> at
> org.apache.calcite.plan.RelWriterTest.testCalc(RelWriterTest.java:688)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: class does not have required
> constructor, class org.apache.calcite.rel.logical.LogicalCalc(RelInput)
> at
> org.apache.calcite.rel.externalize.RelJson.getConstructor(RelJson.java:114)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:98)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.readRels(RelJsonReader.java:91)
> at
> org.apache.calcite.rel.externalize.RelJsonReader.read(RelJsonReader.java:85)
> at
> org.apache.calcite.plan.RelWriterTest.lambda$testCalc$9(RelWriterTest.java:693)
> at
> org.apache.calcite.tools.Frameworks.lambda$withPlanner$0(Frameworks.java:130)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.perform(CalcitePrepareImpl.java:915)
> at org.apache.calcite.tools.Frameworks.withPrepare(Frameworks.java:179)
> ... 25 more
> {code}
> Need to add a public constructor for creating LogicalCalc with RelInput type
> parameter, like this
> {code:java}
> public LogicalCalc(RelInput input)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3319) AssertionError for ReduceDecimalsRule
Wang Yanlin created CALCITE-3319:
Summary: AssertionError for ReduceDecimalsRule
Key: CALCITE-3319
URL: https://issues.apache.org/jira/browse/CALCITE-3319
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When trying to use *ReduceDecimalsRule*, I got
{code:java}
java.lang.AssertionError
at
org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:159)
at
org.apache.calcite.rel.rules.ReduceDecimalsRule$DecimalShuttle.visitCall(ReduceDecimalsRule.java:124)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:191)
at
org.apache.calcite.rex.RexProgramBuilder.add(RexProgramBuilder.java:653)
at
org.apache.calcite.rex.RexProgramBuilder.create(RexProgramBuilder.java:601)
at
org.apache.calcite.rel.rules.ReduceDecimalsRule.onMatch(ReduceDecimalsRule.java:103)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:319)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:560)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:419)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:256)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:127)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:215)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:202)
{code}
I read the code, and found this.
{code:java}
List newOperands = apply(call.getOperands());
if (true) {
// FIXME: Operands are now immutable. Create a new call with
// new operands?
throw new AssertionError();
}
{code}
After remove this logic, the rel below
{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[1.01E1:DOUBLE], expr#9=[15],
expr#10=[+($t8, $t9)], expr#11=[>($t5, $t10)], proj#0..7=[{exprs}],
$condition=[$t11])
LogicalTableScan(table=[[scott, EMP]])
{code}
can be translated into
{code:java}
LogicalCalc(expr#0..7=[{inputs}], expr#8=[Reinterpret($t5)],
expr#9=[CAST($t8):DOUBLE], expr#10=[1E2:DOUBLE], expr#11=[/INT($t9, $t10)],
expr#12=[1.01E1:DOUBLE], expr#13=[15], expr#14=[+($t12, $t13)],
expr#15=[>($t11, $t14)], proj#0..7=[{exprs}], $condition=[$t15])
LogicalTableScan(table=[[scott, EMP]])
{code}
So is this rule not ready for use now, or we should just remove this logic?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3321) Bigquery does not have correct casing rules
Lindsey Meyer created CALCITE-3321: -- Summary: Bigquery does not have correct casing rules Key: CALCITE-3321 URL: https://issues.apache.org/jira/browse/CALCITE-3321 Project: Calcite Issue Type: Bug Reporter: Lindsey Meyer Bigquery has some strange case sensitivity rules, so I think it should leave casing unchanged and make it not case sensitive See rules here: https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical#case_sensitivity -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-3321) Bigquery does not have correct casing rules
[ https://issues.apache.org/jira/browse/CALCITE-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3321: Labels: pull-request-available (was: ) > Bigquery does not have correct casing rules > --- > > Key: CALCITE-3321 > URL: https://issues.apache.org/jira/browse/CALCITE-3321 > Project: Calcite > Issue Type: Bug >Reporter: Lindsey Meyer >Priority: Major > Labels: pull-request-available > > Bigquery has some strange case sensitivity rules, so I think it should leave > casing unchanged and make it not case sensitive > See rules here: > https://cloud.google.com/bigquery/docs/reference/standard-sql/lexical#case_sensitivity -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (CALCITE-2816) PsTableFunction fails in Russian locale
[
https://issues.apache.org/jira/browse/CALCITE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2816:
-
Fix Version/s: 1.22.0
> PsTableFunction fails in Russian locale
> ---
>
> Key: CALCITE-2816
> URL: https://issues.apache.org/jira/browse/CALCITE-2816
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: 1.22.0
>
>
> The issue is present for quite a long time.
> ps output is locale-dependent and parsing is not:
> {noformat}
> [ERROR] testPs(org.apache.calcite.adapter.os.OsAdapterTest) Time elapsed:
> 3.018 s <<< ERROR!
> java.lang.RuntimeException: exception while executing [select * from ps]
> at org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155)
> Caused by: java.lang.RuntimeException: while parsing value [0,1] of field
> [pcpu] in line [ 0 1 1 0 Ss root 0,1 0,0 4367200 5420 ?? 18янв19 106:03.36 0
> 0 0 /sbin/launchd]
> at
> org.apache.calcite.adapter.os.OsAdapterTest.lambda$testPs$3(OsAdapterTest.java:157)
> at
> org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-2816) PsTableFunction fails in Russian locale
[
https://issues.apache.org/jira/browse/CALCITE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921772#comment-16921772
]
Julian Hyde commented on CALCITE-2816:
--
As noted in the [1.21 release
vote|https://lists.apache.org/thread.html/0db442568153f9a8d899f1e1b9c69c60af71cb4c8797b31a833e9036@%3Cdev.calcite.apache.org%3E]
the test fails in Russian and German locales. Even if we don't fix the bug,
could we fix the test? Add something like
{code:java}
Assume.assumeTrue(Locale.getDefault() == Locale.US);{code}
so that the test doesn't get run in locales where we know PsTableFunction is
broken.
> PsTableFunction fails in Russian locale
> ---
>
> Key: CALCITE-2816
> URL: https://issues.apache.org/jira/browse/CALCITE-2816
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> The issue is present for quite a long time.
> ps output is locale-dependent and parsing is not:
> {noformat}
> [ERROR] testPs(org.apache.calcite.adapter.os.OsAdapterTest) Time elapsed:
> 3.018 s <<< ERROR!
> java.lang.RuntimeException: exception while executing [select * from ps]
> at org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155)
> Caused by: java.lang.RuntimeException: while parsing value [0,1] of field
> [pcpu] in line [ 0 1 1 0 Ss root 0,1 0,0 4367200 5420 ?? 18янв19 106:03.36 0
> 0 0 /sbin/launchd]
> at
> org.apache.calcite.adapter.os.OsAdapterTest.lambda$testPs$3(OsAdapterTest.java:157)
> at
> org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-2816) PsTableFunction fails in Russian locale
[
https://issues.apache.org/jira/browse/CALCITE-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921773#comment-16921773
]
Julian Hyde commented on CALCITE-2816:
--
Let's do this for 1.22, so we don't get a false negative in future release
votes.
> PsTableFunction fails in Russian locale
> ---
>
> Key: CALCITE-2816
> URL: https://issues.apache.org/jira/browse/CALCITE-2816
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.18.0
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: 1.22.0
>
>
> The issue is present for quite a long time.
> ps output is locale-dependent and parsing is not:
> {noformat}
> [ERROR] testPs(org.apache.calcite.adapter.os.OsAdapterTest) Time elapsed:
> 3.018 s <<< ERROR!
> java.lang.RuntimeException: exception while executing [select * from ps]
> at org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155)
> Caused by: java.lang.RuntimeException: while parsing value [0,1] of field
> [pcpu] in line [ 0 1 1 0 Ss root 0,1 0,0 4367200 5420 ?? 18янв19 106:03.36 0
> 0 0 /sbin/launchd]
> at
> org.apache.calcite.adapter.os.OsAdapterTest.lambda$testPs$3(OsAdapterTest.java:157)
> at
> org.apache.calcite.adapter.os.OsAdapterTest.testPs(OsAdapterTest.java:155){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CALCITE-3308) RelBuilder.literal with a string argument should create a character literal with appropriate character set
[
https://issues.apache.org/jira/browse/CALCITE-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921718#comment-16921718
]
Justin Swett commented on CALCITE-3308:
---
FWIW, using makeCharLiteral with a NlsString and UTF-8 charset will generate
the correct unicode value but the resulting SQL doesn't execute (in this
example the target DB is MSSQL).
e.g.
{quote}{{rexBuilder.makeCharLiteral(NlsString("İ","UTF-8",
SqlCollation.IMPLICIT))}}
{quote}
{{generates SQL that looks like:}}
{quote}u&'N''\0130'''
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT(*) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = u&'N''\0130'''
{quote}
For MSSQL I was able to override *quoteStringLiteralUnicode* and just write out
the passed in value to the buffer, i.e.
{quote}{{public void quoteStringLiteralUnicode(StringBuilder buf, String val){}}
{{ buf.append(val);}}
{{}}}
{quote}
which produces sql that looks like
{quote}N'İ'
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT(*) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = N'İ'
{quote}
> RelBuilder.literal with a string argument should create a character literal
> with appropriate character set
> --
>
> Key: CALCITE-3308
> URL: https://issues.apache.org/jira/browse/CALCITE-3308
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Suppose you call {{RelBuilder.literal}} with a with a string argument that
> contains non-ASCII characters:
> {code:java}
> RexNode e = RelBuilder.literal("☘️ my lucky charms!");{code}
>
> The call should return a character literal with appropriate character set
> that can handle the contents of the string. (I'm not sure what character set
> should be.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (CALCITE-3308) RelBuilder.literal with a string argument should create a character literal with appropriate character set
[
https://issues.apache.org/jira/browse/CALCITE-3308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921718#comment-16921718
]
Justin Swett edited comment on CALCITE-3308 at 9/3/19 9:01 PM:
---
FWIW, using makeCharLiteral with a NlsString and UTF-8 charset will generate
the correct unicode value but the resulting SQL doesn't execute (in this
example the target DB is MSSQL).
e.g.
{quote}{{rexBuilder.makeCharLiteral(NlsString("İ","UTF-8",
SqlCollation.IMPLICIT))}}
{quote}
{{generates SQL that looks like:}}
{quote}u&'N''\0130'''
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT( * ) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = u&'N''\0130'''
{quote}
For MSSQL I was able to override *quoteStringLiteralUnicode* and just write out
the passed in value to the buffer, i.e.
{quote}{{public void quoteStringLiteralUnicode(StringBuilder buf, String val){}}
{{ buf.append(val);}}
{{}}}
{quote}
which produces sql that looks like
{quote}N'İ'
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT( * ) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = N'İ'
{quote}
was (Author: jswett):
FWIW, using makeCharLiteral with a NlsString and UTF-8 charset will generate
the correct unicode value but the resulting SQL doesn't execute (in this
example the target DB is MSSQL).
e.g.
{quote}{{rexBuilder.makeCharLiteral(NlsString("İ","UTF-8",
SqlCollation.IMPLICIT))}}
{quote}
{{generates SQL that looks like:}}
{quote}u&'N''\0130'''
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT(*) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = u&'N''\0130'''
{quote}
For MSSQL I was able to override *quoteStringLiteralUnicode* and just write out
the passed in value to the buffer, i.e.
{quote}{{public void quoteStringLiteralUnicode(StringBuilder buf, String val){}}
{{ buf.append(val);}}
{{}}}
{quote}
which produces sql that looks like
{quote}N'İ'
specifically,
WITH test_t AS (SELECT (cast(N'İ' as nvarchar)) AS test
UNION ALL
SELECT (cast(N'學校' as nvarchar)) AS test )
SELECT
TOP 1000
COUNT(*) AS "test_t.count"
FROM test_t
WHERE (test_t.test) = N'İ'
{quote}
> RelBuilder.literal with a string argument should create a character literal
> with appropriate character set
> --
>
> Key: CALCITE-3308
> URL: https://issues.apache.org/jira/browse/CALCITE-3308
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Suppose you call {{RelBuilder.literal}} with a with a string argument that
> contains non-ASCII characters:
> {code:java}
> RexNode e = RelBuilder.literal("☘️ my lucky charms!");{code}
>
> The call should return a character literal with appropriate character set
> that can handle the contents of the string. (I'm not sure what character set
> should be.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3320) Use error wrapping in stdlib
Francis Chuang created CALCITE-3320:
---
Summary: Use error wrapping in stdlib
Key: CALCITE-3320
URL: https://issues.apache.org/jira/browse/CALCITE-3320
Project: Calcite
Issue Type: Improvement
Components: avatica-go
Reporter: Francis Chuang
Assignee: Francis Chuang
In Go 1.13, it's possible to wrap errors using `fmt.Errorf("%w", err)`.
We need to update places where errors are wrapped to use the `%w` placeholder.
Use the golang.org/x/xerrors for compatibility with Go versions before 1.13.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3322) There are two same testcase in RelMetadataTest
[
https://issues.apache.org/jira/browse/CALCITE-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3322:
Labels: pull-request-available (was: )
> There are two same testcase in RelMetadataTest
> --
>
> Key: CALCITE-3322
> URL: https://issues.apache.org/jira/browse/CALCITE-3322
> Project: Calcite
> Issue Type: Test
> Components: core
>Affects Versions: 1.20.0
>Reporter: Hong Shen
>Priority: Minor
> Labels: pull-request-available
>
> When I read the code, I found two identical testcases in RelMetadataTest,
> except for the different names, which might need to be changed to limit 0, or
> just need to keep one.
> {code:java}
> @Test public void testRowCountSortLimit() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> @Test public void testRowCountSortLimit0() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3322) There are two same testcase in RelMetadataTest
[
https://issues.apache.org/jira/browse/CALCITE-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hong Shen updated CALCITE-3322:
---
Description:
When I read the code, I found two identical testcases, except for the different
names, which might need to be changed to limit 0, or just need to keep one.
{code:java}
@Test public void testRowCountSortLimit() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
@Test public void testRowCountSortLimit0() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
{code}
was:
When I read the code, I found two identical testcases, except for the different
names, which might need to be changed to limit 0, or just need to keep one.
@Test public void testRowCountSortLimit() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
@Test public void testRowCountSortLimit0() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
> There are two same testcase in RelMetadataTest
> --
>
> Key: CALCITE-3322
> URL: https://issues.apache.org/jira/browse/CALCITE-3322
> Project: Calcite
> Issue Type: Test
> Components: core
>Affects Versions: 1.20.0
>Reporter: Hong Shen
>Priority: Minor
>
> When I read the code, I found two identical testcases, except for the
> different names, which might need to be changed to limit 0, or just need to
> keep one.
> {code:java}
> @Test public void testRowCountSortLimit() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> @Test public void testRowCountSortLimit0() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (CALCITE-3322) There are two same testcase in RelMetadataTest
Hong Shen created CALCITE-3322:
--
Summary: There are two same testcase in RelMetadataTest
Key: CALCITE-3322
URL: https://issues.apache.org/jira/browse/CALCITE-3322
Project: Calcite
Issue Type: Test
Components: core
Affects Versions: 1.20.0
Reporter: Hong Shen
When I read the code, I found two identical testcases, except for the different
names, which might need to be changed to limit 0, or just need to keep one.
@Test public void testRowCountSortLimit() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
@Test public void testRowCountSortLimit0() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (CALCITE-3322) There are two same testcase in RelMetadataTest
[
https://issues.apache.org/jira/browse/CALCITE-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hong Shen updated CALCITE-3322:
---
Description:
When I read the code, I found two identical testcases in RelMetadataTest,
except for the different names, which might need to be changed to limit 0, or
just need to keep one.
{code:java}
@Test public void testRowCountSortLimit() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
@Test public void testRowCountSortLimit0() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
{code}
was:
When I read the code, I found two identical testcases, except for the different
names, which might need to be changed to limit 0, or just need to keep one.
{code:java}
@Test public void testRowCountSortLimit() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
@Test public void testRowCountSortLimit0() {
final String sql = "select * from emp order by ename limit 10";
checkRowCount(sql, 10d, 0D, 10d);
}
{code}
> There are two same testcase in RelMetadataTest
> --
>
> Key: CALCITE-3322
> URL: https://issues.apache.org/jira/browse/CALCITE-3322
> Project: Calcite
> Issue Type: Test
> Components: core
>Affects Versions: 1.20.0
>Reporter: Hong Shen
>Priority: Minor
>
> When I read the code, I found two identical testcases in RelMetadataTest,
> except for the different names, which might need to be changed to limit 0, or
> just need to keep one.
> {code:java}
> @Test public void testRowCountSortLimit() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> @Test public void testRowCountSortLimit0() {
> final String sql = "select * from emp order by ename limit 10";
> checkRowCount(sql, 10d, 0D, 10d);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
