[jira] [Created] (CALCITE-3246) NullPointerException while deserializing of udf.
Wang Yanlin created CALCITE-3246:
Summary: NullPointerException while deserializing of udf.
Key: CALCITE-3246
URL: https://issues.apache.org/jira/browse/CALCITE-3246
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Wang Yanlin
when deserializing of logical rel with udf operator, NPE occurs.
The exception stacktrace as follow.
{code:java}
java.lang.RuntimeException: java.lang.NullPointerException
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.testUdf(RelWriterTest.java:598)
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.NullPointerException
at java.util.Objects.requireNonNull(Objects.java:203)
at org.apache.calcite.rex.RexCall.(RexCall.java:83)
at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:237)
at org.apache.calcite.rel.externalize.RelJson.toRex(RelJson.java:485)
at
org.apache.calcite.rel.externalize.RelJsonReader$2.getExpressionList(RelJsonReader.java:204)
at org.apache.calcite.rel.core.Project.(Project.java:100)
at
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:88)
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.rel.externalize.RelJsonReader.readRel(RelJsonReader.java:261)
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$testUdf$7(RelWriterTest.java:603)
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}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905847#comment-16905847
]
Julian Feinauer commented on CALCITE-1935:
--
Thank you very much [~danny0405]!
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Feinauer
>Priority: Major
> Labels: match
> Fix For: 1.21.0
>
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905749#comment-16905749
]
Danny Chan edited comment on CALCITE-3238 at 8/13/19 2:34 AM:
--
I agree with your point that we should firstly consider model the grammar
first, the difficult thing is that i need to parse the precision/scale between
the actual "time/timestamp" and "with local time zone".
I put the parse for all the data types just like the " ", which
i think also have the same problem.
I will try to do some refactoring, thanks.
was (Author: danny0405):
I agree with your point that we should firstly consider model the grammar
first, the difficult thing is that i need to parse the precision/scale between
the actually "time/timestamp" and "with local time zone".
I put the parse for all the data types just like the " ", which
i think also have the same problem.
I will try to do some refactoring, thanks.
> Support Time Zone suffix of DateTime types for SqlDataTypeSpec
> --
>
> Key: CALCITE-3238
> URL: https://issues.apache.org/jira/browse/CALCITE-3238
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is the grammar copied from SQL-2011:
> {code:sql}
> ::=
> DATE
> | TIME [] [ time zone> ]
> | TIMESTAMP []
> [ ]
> ::=
> WITH TIME ZONE
> | WITHOUT TIME ZONE
> ::=
>
> ::=
>
> ::=
>
> {code}
> We extend this grammar to support "with local time zone" definition:
> {code:sql}
> time(0) with local time zone
> timestamp(0) with local time zone
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905749#comment-16905749
]
Danny Chan commented on CALCITE-3238:
-
I agree with your point that we should firstly consider model the grammar
first, the difficult thing is that i need to parse the precision/scale between
the actually "time/timestamp" and "with local time zone".
I put the parse for all the data types just like the " ", which
i think also have the same problem.
I will try to do some refactoring, thanks.
> Support Time Zone suffix of DateTime types for SqlDataTypeSpec
> --
>
> Key: CALCITE-3238
> URL: https://issues.apache.org/jira/browse/CALCITE-3238
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is the grammar copied from SQL-2011:
> {code:sql}
> ::=
> DATE
> | TIME [] [ time zone> ]
> | TIMESTAMP []
> [ ]
> ::=
> WITH TIME ZONE
> | WITHOUT TIME ZONE
> ::=
>
> ::=
>
> ::=
>
> {code}
> We extend this grammar to support "with local time zone" definition:
> {code:sql}
> time(0) with local time zone
> timestamp(0) with local time zone
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-3214) Add UnionToUnionRule for materialization matching
[
https://issues.apache.org/jira/browse/CALCITE-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing reassigned CALCITE-3214:
-
Assignee: jin xing
> Add UnionToUnionRule for materialization matching
> -
>
> Key: CALCITE-3214
> URL: https://issues.apache.org/jira/browse/CALCITE-3214
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Below materialization matching fails now
> {code:java}
> @Test public void testDEV() {
> String sql0 = "select * from \"emps\" where \"empid\" < 300";
> String sql1 = "select * from \"emps\" where \"empid\" > 200";
> checkMaterialize(sql0 + " union all " + sql1, sql1 + " union all " +
> sql0);
> }
> {code}
> This issue proposes to add a rule for union matching
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905746#comment-16905746
]
Danny Chan commented on CALCITE-1935:
-
Nice job, [~julian.feinauer] ! Thanks for your contribution ~:D
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Feinauer
>Priority: Major
> Labels: match
> Fix For: 1.21.0
>
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-3223) Non-RexInputRef may fails the matching of FilterToProjectUnifyRule during 'invert' by mistake.
[
https://issues.apache.org/jira/browse/CALCITE-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing reassigned CALCITE-3223:
-
Assignee: jin xing
> Non-RexInputRef may fails the matching of FilterToProjectUnifyRule during
> 'invert' by mistake.
> --
>
> Key: CALCITE-3223
> URL: https://issues.apache.org/jira/browse/CALCITE-3223
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In current code of
> {{FilterToProjectUnifyRule::invert}}(https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L1124),
> the implementation
> 1. Fails the matching when there is Non-RexInputRef in the projects
> 2. Didn't check if all items of {{exprList}} has already been set correctly.
> As a result below tests fails.
> {code:java}
> @Test public void testFilterToProject0() {
> String union =
> "select * from \"emps\" where \"empid\" > 300\n"
> + "union all select * from \"emps\" where \"empid\" < 200";
> String mv = "select *, \"empid\" * 2 from (" + union + ")";
> String query = "select * from (" + union + ") where (\"empid\" * 2) > 3";
> checkMaterialize(mv, query);
> }
> @Test public void testFilterToProject1() {
> String agg =
> "select \"deptno\", count(*) as \"c\", sum(\"salary\") as \"s\"\n"
> + "from \"emps\" group by \"deptno\"";
> String mv = "select \"c\", \"s\", \"s\" from (" + agg + ")";
> String query = "select * from (" + agg + ") where (\"s\" * 0.8) > 1";
> checkNoMaterialize(mv, query, HR_FKUK_MODEL);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-3243) Incomplete validation of operands in JSON functions
[
https://issues.apache.org/jira/browse/CALCITE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905731#comment-16905731
]
Matt Wang edited comment on CALCITE-3243 at 8/13/19 2:05 AM:
-
[~zabetak]
I think the error was thrown in validate phase. I run this test
{code:java}
//tester.checkString("json_value(true, 'strict $.foo' default 'empty' on
error)", "empty", "VARCHAR(2000)");{code}
which throws exception like this:
{code:java}
//
org.apache.calcite.runtime.CalciteContextException: From line 1, column 20 to
line 1, column 23: Cannot apply 'JSON_VALUE_EXPRESSION' to arguments of type
'JSON_VALUE_EXPRESSION()'. Supported form(s):
'JSON_VALUE_EXPRESSION()'
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:787)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:772)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4816)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:109)
at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:665)
at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:515)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5575)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5562)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1646)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at org.apache.calcite.sql.SqlFunction.validateCall(SqlFunction.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:943)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:637)
at
org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:172)
at
org.apache.calcite.sql.test.AbstractSqlTester.getResultType(AbstractSqlTester.java:157)
at
org.apache.calcite.sql.test.AbstractSqlTester.getColumnType(AbstractSqlTester.java:149)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:466)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest$TesterImpl.check(SqlOperatorBaseTest.java:8170)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:451)
at
org.apache.calcite.sql.test.AbstractSqlTester.checkString(AbstractSqlTester.java:436)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest.testJsonValue(SqlOperatorBaseTest.java:4365)
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
[jira] [Comment Edited] (CALCITE-3243) Incomplete validation of operands in JSON functions
[
https://issues.apache.org/jira/browse/CALCITE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905731#comment-16905731
]
Matt Wang edited comment on CALCITE-3243 at 8/13/19 2:05 AM:
-
[~zabetak]
I think the error was thrown in validate phase. I run this test
{code:java}
tester.checkString("json_value(true, 'strict $.foo' default 'empty' on error)",
"empty", "VARCHAR(2000)");{code}
which throws exception like this:
{code:java}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 20 to
line 1, column 23: Cannot apply 'JSON_VALUE_EXPRESSION' to arguments of type
'JSON_VALUE_EXPRESSION()'. Supported form(s):
'JSON_VALUE_EXPRESSION()'
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:787)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:772)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4816)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:109)
at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:665)
at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:515)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5575)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5562)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1646)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at org.apache.calcite.sql.SqlFunction.validateCall(SqlFunction.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:943)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:637)
at
org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:172)
at
org.apache.calcite.sql.test.AbstractSqlTester.getResultType(AbstractSqlTester.java:157)
at
org.apache.calcite.sql.test.AbstractSqlTester.getColumnType(AbstractSqlTester.java:149)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:466)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest$TesterImpl.check(SqlOperatorBaseTest.java:8170)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:451)
at
org.apache.calcite.sql.test.AbstractSqlTester.checkString(AbstractSqlTester.java:436)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest.testJsonValue(SqlOperatorBaseTest.java:4365)
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
[jira] [Commented] (CALCITE-3243) Incomplete validation of operands in JSON functions
[
https://issues.apache.org/jira/browse/CALCITE-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905731#comment-16905731
]
Matt Wang commented on CALCITE-3243:
[~zabetak]
I think the error was thrown in validate phase. I run this test
```java
tester.checkString("json_value(true, 'strict $.foo' default 'empty' on
error)", "empty", "VARCHAR(2000)");
```
which throws exception like this:
```sh
org.apache.calcite.runtime.CalciteContextException: From line 1, column 20 to
line 1, column 23: Cannot apply 'JSON_VALUE_EXPRESSION' to arguments of type
'JSON_VALUE_EXPRESSION()'. Supported form(s):
'JSON_VALUE_EXPRESSION()'
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:787)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:772)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4816)
at
org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:280)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92)
at
org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:109)
at org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:665)
at org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:432)
at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:515)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5575)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5562)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1661)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1646)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:236)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at org.apache.calcite.sql.SqlFunction.validateCall(SqlFunction.java:196)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:235)
at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:407)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:5279)
at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:116)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:943)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:637)
at
org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:172)
at
org.apache.calcite.sql.test.AbstractSqlTester.getResultType(AbstractSqlTester.java:157)
at
org.apache.calcite.sql.test.AbstractSqlTester.getColumnType(AbstractSqlTester.java:149)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:466)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest$TesterImpl.check(SqlOperatorBaseTest.java:8170)
at
org.apache.calcite.sql.test.AbstractSqlTester.check(AbstractSqlTester.java:451)
at
org.apache.calcite.sql.test.AbstractSqlTester.checkString(AbstractSqlTester.java:436)
at
org.apache.calcite.sql.test.SqlOperatorBaseTest.testJsonValue(SqlOperatorBaseTest.java:4365)
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
[jira] [Assigned] (CALCITE-3159) Distinct can be removed for MIN/MAX/BIT_OR/BIT_AND aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3159:
Assignee: Julian Hyde (was: Forward Xu)
> Distinct can be removed for MIN/MAX/BIT_OR/BIT_AND aggregate functions
> --
>
> Key: CALCITE-3159
> URL: https://issues.apache.org/jira/browse/CALCITE-3159
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For the following query:
> {code:java}
> select a, min(distinct b), bit_or(distinct c) from foo group by a;
> {code}
> Currently Calcite still preserve the distinct for these aggregate functions,
> but DISTINCT is not meaningful with MIN/MAX and is available for ISO
> compatibility only. We can safely remove distinct and get more optimization
> opportunities.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3159) Distinct can be removed for MIN/MAX/BIT_OR/BIT_AND aggregate functions
[
https://issues.apache.org/jira/browse/CALCITE-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905717#comment-16905717
]
Julian Hyde commented on CALCITE-3159:
--
Reviewing now. Will commit shortly.
> Distinct can be removed for MIN/MAX/BIT_OR/BIT_AND aggregate functions
> --
>
> Key: CALCITE-3159
> URL: https://issues.apache.org/jira/browse/CALCITE-3159
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> For the following query:
> {code:java}
> select a, min(distinct b), bit_or(distinct c) from foo group by a;
> {code}
> Currently Calcite still preserve the distinct for these aggregate functions,
> but DISTINCT is not meaningful with MIN/MAX and is available for ISO
> compatibility only. We can safely remove distinct and get more optimization
> opportunities.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3245) CompileException in Janino when a query contains a division between a Double and a BigDecimal
[
https://issues.apache.org/jira/browse/CALCITE-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905672#comment-16905672
]
Stamatis Zampetakis commented on CALCITE-3245:
--
As it is clearly indicated in the exception message in line 23 the division
returns a double and there is a wrong cast to BigDecimal.
> CompileException in Janino when a query contains a division between a Double
> and a BigDecimal
> -
>
> Key: CALCITE-3245
> URL: https://issues.apache.org/jira/browse/CALCITE-3245
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> A CompileException in Janino is raised when the SQL query contains a division
> operator between a column of type Double and a column of type BigDecimal.
> The following test added in {{ReflectiveSchemaTest}} can reproduce the
> problem.
> {code:java}
> @Test public void testDivideDoubleBigDecimal() {
> final CalciteAssert.AssertThat with =
> CalciteAssert.that().withSchema("s", CATCHALL);
> with.query("select \"wrapperDouble\" / \"bigDecimal\" as c\n"
> + " from \"s\".\"everyTypes\"")
> .runs();
> }
> {code}
> The generated code is the following:
> {code:java}
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.apache.calcite.test.ReflectiveSchemaTest.CatchallSchema)
> ((org.apache.calcite.adapter.java.ReflectiveSchema)
> root.getRootSchema().getSubSchema("s").unwrap(org.apache.calcite.adapter.java.ReflectiveSchema.class)).getTarget()).everyTypes);
> return new org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator
> = _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final org.apache.calcite.test.ReflectiveSchemaTest.EveryType
> current = (org.apache.calcite.test.ReflectiveSchemaTest.EveryType)
> inputEnumerator.current();
> final Double inp15_ = current.wrapperDouble;
> final java.math.BigDecimal inp21_ = current.bigDecimal;
> return inp15_ == null || inp21_ == null ?
> (java.math.BigDecimal) null : (java.math.BigDecimal) (inp15_.doubleValue() /
> inp21_.doubleValue());
> }
> };
> }
> };
> }
> public Class getElementType() {
> return java.math.BigDecimal.class;
> }
> {code}
> and the stack trace is given below:
> {noformat}
> Caused by: java.lang.RuntimeException: Error while compiling generated Java
> code:
> ...
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1110)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:638)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:502)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:472)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> ... 28 more
> Caused by: org.codehaus.commons.compiler.CompileException: Line 23, Column
> 111: Cannot cast "double" to "java.math.BigDecimal"
> at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
> at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5051)
> at org.codehaus.janino.UnitCompiler.access$8600(UnitCompiler.java:215)
> at
[jira] [Created] (CALCITE-3245) CompileException in Janino when a query contains a division between a Double and a BigDecimal
Stamatis Zampetakis created CALCITE-3245:
Summary: CompileException in Janino when a query contains a
division between a Double and a BigDecimal
Key: CALCITE-3245
URL: https://issues.apache.org/jira/browse/CALCITE-3245
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.20.0
Reporter: Stamatis Zampetakis
A CompileException in Janino is raised when the SQL query contains a division
operator between a column of type Double and a column of type BigDecimal.
The following test added in {{ReflectiveSchemaTest}} can reproduce the problem.
{code:java}
@Test public void testDivideDoubleBigDecimal() {
final CalciteAssert.AssertThat with =
CalciteAssert.that().withSchema("s", CATCHALL);
with.query("select \"wrapperDouble\" / \"bigDecimal\" as c\n"
+ " from \"s\".\"everyTypes\"")
.runs();
}
{code}
The generated code is the following:
{code:java}
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root) {
final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
org.apache.calcite.linq4j.Linq4j.asEnumerable(((org.apache.calcite.test.ReflectiveSchemaTest.CatchallSchema)
((org.apache.calcite.adapter.java.ReflectiveSchema)
root.getRootSchema().getSubSchema("s").unwrap(org.apache.calcite.adapter.java.ReflectiveSchema.class)).getTarget()).everyTypes);
return new org.apache.calcite.linq4j.AbstractEnumerable(){
public org.apache.calcite.linq4j.Enumerator enumerator() {
return new org.apache.calcite.linq4j.Enumerator(){
public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
_inputEnumerable.enumerator();
public void reset() {
inputEnumerator.reset();
}
public boolean moveNext() {
return inputEnumerator.moveNext();
}
public void close() {
inputEnumerator.close();
}
public Object current() {
final org.apache.calcite.test.ReflectiveSchemaTest.EveryType
current = (org.apache.calcite.test.ReflectiveSchemaTest.EveryType)
inputEnumerator.current();
final Double inp15_ = current.wrapperDouble;
final java.math.BigDecimal inp21_ = current.bigDecimal;
return inp15_ == null || inp21_ == null ? (java.math.BigDecimal)
null : (java.math.BigDecimal) (inp15_.doubleValue() / inp21_.doubleValue());
}
};
}
};
}
public Class getElementType() {
return java.math.BigDecimal.class;
}
{code}
and the stack trace is given below:
{noformat}
Caused by: java.lang.RuntimeException: Error while compiling generated Java
code:
...
at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
at
org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
at
org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1110)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:332)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:638)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:502)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:472)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:550)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
... 28 more
Caused by: org.codehaus.commons.compiler.CompileException: Line 23, Column 111:
Cannot cast "double" to "java.math.BigDecimal"
at
org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12211)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5051)
at org.codehaus.janino.UnitCompiler.access$8600(UnitCompiler.java:215)
at org.codehaus.janino.UnitCompiler$16.visitCast(UnitCompiler.java:4418)
at org.codehaus.janino.UnitCompiler$16.visitCast(UnitCompiler.java:4396)
at org.codehaus.janino.Java$Cast.accept(Java.java:4898)
at org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4396)
at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5662)
at org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4716)
at org.codehaus.janino.UnitCompiler.access$8800(UnitCompiler.java:215)
at
[jira] [Commented] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905584#comment-16905584
]
Julian Hyde commented on CALCITE-3238:
--
Why do you allow WITH LOCAL TIME ZONE for all types, then validate? Why not
just model it using grammar? It's generally a bad idea to do "validation" (and
throw errors) in the parser.
> Support Time Zone suffix of DateTime types for SqlDataTypeSpec
> --
>
> Key: CALCITE-3238
> URL: https://issues.apache.org/jira/browse/CALCITE-3238
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is the grammar copied from SQL-2011:
> {code:sql}
> ::=
> DATE
> | TIME [] [ time zone> ]
> | TIMESTAMP []
> [ ]
> ::=
> WITH TIME ZONE
> | WITHOUT TIME ZONE
> ::=
>
> ::=
>
> ::=
>
> {code}
> We extend this grammar to support "with local time zone" definition:
> {code:sql}
> time(0) with local time zone
> timestamp(0) with local time zone
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905538#comment-16905538
]
Julian Feinauer commented on CALCITE-1935:
--
Thank you so much [~julianhyde] for your support and the final polishing. I am
very happy that I was finally able to contribute something 'major' to calcite!
I hope that I'm able to improve MATCH_RECOGNIZE in the future.
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Feinauer
>Priority: Major
> Labels: match
> Fix For: 1.21.0
>
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1935.
--
Resolution: Fixed
Fix Version/s: 1.21.0
Fixed in
[5ec3a2a|https://github.com/apache/calcite/commit/5ec3a2a503dcf26fe1b3cad8a5a9467264213dcf]
(and the preceding 2 commits).
{{MATCH_RECOGNIZE}} is not fully working, but now the basics are working we can
iterate. Thanks to [~julian.feinauer] and [~ransom] for your contributions.
Especially thanks to [~julian.feinauer] for your perseverance. This is a huge,
complex feature and it was a marathon to get it done.
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Feinauer
>Priority: Major
> Labels: match
> Fix For: 1.21.0
>
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3241) Calcite this is a very strange mistake
[
https://issues.apache.org/jira/browse/CALCITE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905500#comment-16905500
]
Julian Hyde commented on CALCITE-3241:
--
[~1693294577], You need to make a much clearer case that this is a bug in
Calcite, as opposed to some other project. I see a lot of other projects' code
on the stack. Also, you need to be more precise what you think Calcite is doing
wrong and what the correct behavior should be. Otherwise you are wasting our
time asking us to investigate this.
> Calcite this is a very strange mistake
> --
>
> Key: CALCITE-3241
> URL: https://issues.apache.org/jira/browse/CALCITE-3241
> Project: Calcite
> Issue Type: Bug
>Reporter: ;ianghaibin
>Priority: Major
>
> 0: jdbc:calcite:model=/root/calcite/apache-ca> select sum("xxx") as a from
> "xxx";
> java.lang.NumberFormatException: For input string: "13485468068"
> at
> ru.yandex.clickhouse.response.ByteFragmentUtils.parseInt(ByteFragmentUtils.java:61)
> at
> ru.yandex.clickhouse.response.ClickHouseResultSet.getInt(ClickHouseResultSet.java:342)
> at
> org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
> at
> org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
> at Baz$1$1.apply(Unknown Source)
> at
> org.apache.calcite.runtime.ResultSetEnumerable$ResultSetEnumerator.current(ResultSetEnumerable.java:365)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at sqlline.BufferedRows.nextList(BufferedRows.java:110)
> at sqlline.BufferedRows.(BufferedRows.java:52)
> at sqlline.SqlLine.print(SqlLine.java:1640)
> at sqlline.Commands.executeSingleQuery(Commands.java:1017)
> at sqlline.Commands.execute(Commands.java:957)
> at sqlline.Commands.sql(Commands.java:921)
> at sqlline.SqlLine.dispatch(SqlLine.java:717)
> at sqlline.SqlLine.begin(SqlLine.java:536)
> at sqlline.SqlLine.start(SqlLine.java:266)
> at sqlline.SqlLine.main(SqlLine.java:205)
> The data I got is integer, and I am getting an error.
> However, this is not an error.
> select "xx","xx",sum("xx") as xx from "xx" group by "xx","xxx" limit 1;
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3242) RelToSqlConverter handling "NOT IN" incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905497#comment-16905497
]
Julian Hyde commented on CALCITE-3242:
--
{quote}NOT IN comes as RexCall{quote} Comes from where?
> RelToSqlConverter handling "NOT IN" incorrectly
> ---
>
> Key: CALCITE-3242
> URL: https://issues.apache.org/jira/browse/CALCITE-3242
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Atharv Rajput
>Assignee: Atharv Rajput
>Priority: Minor
> Fix For: 1.21.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When RelNode is having `NOT IN` operator, it's being converted incorrectly by
> RelToSqlConverter. For example
> {code:java}
> @Test public void testNotInOperator() {
> final RelBuilder builder = relBuilder().scan("EMP");
> final RexNode condition =
> builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
> builder.literal(20), builder.literal(30));
> final RelNode root = relBuilder().scan("EMP").filter(condition).build();
> final String sql = toSql(root);
> final String expectedSql = "SELECT *\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"DEPTNO\" NOT IN (20, 30)";
> assertThat(sql, isLinux(expectedSql));
> }
> {code}
> Above test fails with error:
> {code:java}
> Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
> 30)"
> but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
> 30"
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3242) RelToSqlConverter handling "NOT IN" incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905487#comment-16905487
]
Atharv Rajput commented on CALCITE-3242:
Thanks for your reply [~julianhyde], but NOT IN comes as RexCall:
{code:java}
condition = {RexCall@3809} "NOT IN($7, 20, 30)"
op = {SqlInOperator@3852} "NOT IN"
operands = {RegularImmutableList@3853} size = 3
0 = {RexInputRef@3858} "$7"
1 = {RexLiteral@3859} "20"
2 = {RexLiteral@3860} "30"
type = {BasicSqlType@3854} "BOOLEAN"
digest = "NOT IN($7, 20, 30)"{code}
Let me know if this is expected behavior.
> RelToSqlConverter handling "NOT IN" incorrectly
> ---
>
> Key: CALCITE-3242
> URL: https://issues.apache.org/jira/browse/CALCITE-3242
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Atharv Rajput
>Assignee: Atharv Rajput
>Priority: Minor
> Fix For: 1.21.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When RelNode is having `NOT IN` operator, it's being converted incorrectly by
> RelToSqlConverter. For example
> {code:java}
> @Test public void testNotInOperator() {
> final RelBuilder builder = relBuilder().scan("EMP");
> final RexNode condition =
> builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
> builder.literal(20), builder.literal(30));
> final RelNode root = relBuilder().scan("EMP").filter(condition).build();
> final String sql = toSql(root);
> final String expectedSql = "SELECT *\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"DEPTNO\" NOT IN (20, 30)";
> assertThat(sql, isLinux(expectedSql));
> }
> {code}
> Above test fails with error:
> {code:java}
> Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
> 30)"
> but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
> 30"
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3244) Decorrelating sub-queries - Adding Implicit RowID support
[
https://issues.apache.org/jira/browse/CALCITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905485#comment-16905485
]
Julian Hyde commented on CALCITE-3244:
--
There's a lot of Drill-specific stuff in this case. I don't even know what a
"RowID" is. The error messages are all from Drill. ValuesPrel is a class in
Drill.
Can you rework this case so that it has a value proposition for Calcite users?
I fear that this is doing to be another "Drill-a-hole" request that allows
Drill to do what it does but offers nothing to Calcite users. Please prove me
wrong.
> Decorrelating sub-queries - Adding Implicit RowID support
> -
>
> Key: CALCITE-3244
> URL: https://issues.apache.org/jira/browse/CALCITE-3244
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.20.0
>Reporter: benj
>Priority: Major
>
> Some very useful type of requests currently failed with:
> {code:java}
> SYSTEM ERROR: UnsupportedOperationException: Adding Implicit RowID column is
> not supported for ValuesPrel operator
> {code}
> Examples from DRILL-7050:
> {code:sql}
> select t1.id,
> (select count(t2.id)
> from (
> select 1 as id
> union all
> select 2 as id
> ) t2 where t2.id = t1.id)
> from (
> select 1 as id
> union all
> select 2 as id
> ) t1
> {code}
> {code:sql}
> SELECT t,
> (SELECT count(*) FROM
> (SELECT split(r,' ') AS r FROM
> (SELECT sub.t AS r)) AS x
> ,LATERAL(SELECT $unnest AS u FROM unnest(x.r))
> /* WHERE ... */) t2
> FROM
> (SELECT 'unnest is useful' AS t) sub
> {code}
>
> _Please note that in 1.18 the error for these requests was:_
> {code:java}
> Error: PLAN ERROR: Cannot convert RexNode to equivalent Drill expression.
> RexNode Class: org.apache.calcite.rex.RexCorrelVariable, RexNode Digest: $cor0
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3244) Decorrelating sub-queries - Adding Implicit RowID support
benj created CALCITE-3244:
-
Summary: Decorrelating sub-queries - Adding Implicit RowID support
Key: CALCITE-3244
URL: https://issues.apache.org/jira/browse/CALCITE-3244
Project: Calcite
Issue Type: Improvement
Affects Versions: 1.20.0
Reporter: benj
Some very useful type of requests currently failed with:
{code:java}
SYSTEM ERROR: UnsupportedOperationException: Adding Implicit RowID column is
not supported for ValuesPrel operator
{code}
Examples from DRILL-7050:
{code:sql}
select t1.id,
(select count(t2.id)
from (
select 1 as id
union all
select 2 as id
) t2 where t2.id = t1.id)
from (
select 1 as id
union all
select 2 as id
) t1
{code}
{code:sql}
SELECT t,
(SELECT count(*) FROM
(SELECT split(r,' ') AS r FROM
(SELECT sub.t AS r)) AS x
,LATERAL(SELECT $unnest AS u FROM unnest(x.r))
/* WHERE ... */) t2
FROM
(SELECT 'unnest is useful' AS t) sub
{code}
_Please note that in 1.18 the error for these requests was:_
{code:java}
Error: PLAN ERROR: Cannot convert RexNode to equivalent Drill expression.
RexNode Class: org.apache.calcite.rex.RexCorrelVariable, RexNode Digest: $cor0
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3242) RelToSqlConverter handling "NOT IN" incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905264#comment-16905264
]
Julian Hyde commented on CALCITE-3242:
--
I don’t think we support NOT-IN as a RexCall, so this issue is invalid.
> RelToSqlConverter handling "NOT IN" incorrectly
> ---
>
> Key: CALCITE-3242
> URL: https://issues.apache.org/jira/browse/CALCITE-3242
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Atharv Rajput
>Assignee: Atharv Rajput
>Priority: Minor
> Fix For: 1.21.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When RelNode is having `NOT IN` operator, it's being converted incorrectly by
> RelToSqlConverter. For example
> {code:java}
> @Test public void testNotInOperator() {
> final RelBuilder builder = relBuilder().scan("EMP");
> final RexNode condition =
> builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
> builder.literal(20), builder.literal(30));
> final RelNode root = relBuilder().scan("EMP").filter(condition).build();
> final String sql = toSql(root);
> final String expectedSql = "SELECT *\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"DEPTNO\" NOT IN (20, 30)";
> assertThat(sql, isLinux(expectedSql));
> }
> {code}
> Above test fails with error:
> {code:java}
> Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
> 30)"
> but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
> 30"
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3241) Calcite this is a very strange mistake
[
https://issues.apache.org/jira/browse/CALCITE-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905076#comment-16905076
]
Chris Baynes commented on CALCITE-3241:
---
It looks like you are trying to sum a column that has a String type in
Clickhouse. If that's the case, then this isn't going to work.
What are the column types you're interacting with here?
> Calcite this is a very strange mistake
> --
>
> Key: CALCITE-3241
> URL: https://issues.apache.org/jira/browse/CALCITE-3241
> Project: Calcite
> Issue Type: Bug
>Reporter: ;ianghaibin
>Priority: Major
>
> 0: jdbc:calcite:model=/root/calcite/apache-ca> select sum("xxx") as a from
> "xxx";
> java.lang.NumberFormatException: For input string: "13485468068"
> at
> ru.yandex.clickhouse.response.ByteFragmentUtils.parseInt(ByteFragmentUtils.java:61)
> at
> ru.yandex.clickhouse.response.ClickHouseResultSet.getInt(ClickHouseResultSet.java:342)
> at
> org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
> at
> org.apache.commons.dbcp2.DelegatingResultSet.getInt(DelegatingResultSet.java:623)
> at Baz$1$1.apply(Unknown Source)
> at
> org.apache.calcite.runtime.ResultSetEnumerable$ResultSetEnumerator.current(ResultSetEnumerable.java:365)
> at org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:683)
> at org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46)
> at org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:217)
> at sqlline.BufferedRows.nextList(BufferedRows.java:110)
> at sqlline.BufferedRows.(BufferedRows.java:52)
> at sqlline.SqlLine.print(SqlLine.java:1640)
> at sqlline.Commands.executeSingleQuery(Commands.java:1017)
> at sqlline.Commands.execute(Commands.java:957)
> at sqlline.Commands.sql(Commands.java:921)
> at sqlline.SqlLine.dispatch(SqlLine.java:717)
> at sqlline.SqlLine.begin(SqlLine.java:536)
> at sqlline.SqlLine.start(SqlLine.java:266)
> at sqlline.SqlLine.main(SqlLine.java:205)
> The data I got is integer, and I am getting an error.
> However, this is not an error.
> select "xx","xx",sum("xx") as xx from "xx" group by "xx","xxx" limit 1;
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3238:
Labels: pull-request-available (was: )
> Support Time Zone suffix of DateTime types for SqlDataTypeSpec
> --
>
> Key: CALCITE-3238
> URL: https://issues.apache.org/jira/browse/CALCITE-3238
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
>
> This is the grammar copied from SQL-2011:
> {code:sql}
> ::=
> DATE
> | TIME [] [ time zone> ]
> | TIMESTAMP []
> [ ]
> ::=
> WITH TIME ZONE
> | WITHOUT TIME ZONE
> ::=
>
> ::=
>
> ::=
>
> {code}
> We extend this grammar to support "with local time zone" definition:
> {code:sql}
> time(0) with local time zone
> timestamp(0) with local time zone
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3238) Support Time Zone suffix of DateTime types for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan updated CALCITE-3238:
Description:
This is the grammar copied from SQL-2011:
{code:sql}
::=
DATE
| TIME [] [ ]
| TIMESTAMP []
[ ]
::=
WITH TIME ZONE
| WITHOUT TIME ZONE
::=
::=
::=
{code}
We extend this grammar to support "with local time zone" definition:
{code:sql}
time(0) with local time zone
timestamp(0) with local time zone
{code}
was:
This is the grammar copied from SQL-2011:
{code:sql}
::=
DATE
| TIME [] [ ]
| TIMESTAMP []
[ ]
::=
WITH TIME ZONE
| WITHOUT TIME ZONE
::=
::=
::=
{code}
> Support Time Zone suffix of DateTime types for SqlDataTypeSpec
> --
>
> Key: CALCITE-3238
> URL: https://issues.apache.org/jira/browse/CALCITE-3238
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
>
> This is the grammar copied from SQL-2011:
> {code:sql}
> ::=
> DATE
> | TIME [] [ time zone> ]
> | TIMESTAMP []
> [ ]
> ::=
> WITH TIME ZONE
> | WITHOUT TIME ZONE
> ::=
>
> ::=
>
> ::=
>
> {code}
> We extend this grammar to support "with local time zone" definition:
> {code:sql}
> time(0) with local time zone
> timestamp(0) with local time zone
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3242) RelToSqlConverter handling "NOT IN" incorrectly
[
https://issues.apache.org/jira/browse/CALCITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atharv Rajput updated CALCITE-3242:
---
Summary: RelToSqlConverter handling "NOT IN" incorrectly (was:
RelToSqlConverter not handling "NOT IN" properly)
> RelToSqlConverter handling "NOT IN" incorrectly
> ---
>
> Key: CALCITE-3242
> URL: https://issues.apache.org/jira/browse/CALCITE-3242
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Atharv Rajput
>Assignee: Atharv Rajput
>Priority: Minor
> Fix For: 1.21.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When RelNode is having `NOT IN` operator, it's being converted incorrectly by
> RelToSqlConverter. For example
> {code:java}
> @Test public void testNotInOperator() {
> final RelBuilder builder = relBuilder().scan("EMP");
> final RexNode condition =
> builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
> builder.literal(20), builder.literal(30));
> final RelNode root = relBuilder().scan("EMP").filter(condition).build();
> final String sql = toSql(root);
> final String expectedSql = "SELECT *\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"DEPTNO\" NOT IN (20, 30)";
> assertThat(sql, isLinux(expectedSql));
> }
> {code}
> Above test fails with error:
> {code:java}
> Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
> 30)"
> but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
> 30"
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3242) RelToSqlConverter not handling "NOT IN" properly
[
https://issues.apache.org/jira/browse/CALCITE-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atharv Rajput updated CALCITE-3242:
---
Remaining Estimate: 1h
Original Estimate: 1h
> RelToSqlConverter not handling "NOT IN" properly
>
>
> Key: CALCITE-3242
> URL: https://issues.apache.org/jira/browse/CALCITE-3242
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Atharv Rajput
>Assignee: Atharv Rajput
>Priority: Minor
> Fix For: 1.21.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> When RelNode is having `NOT IN` operator, it's being converted incorrectly by
> RelToSqlConverter. For example
> {code:java}
> @Test public void testNotInOperator() {
> final RelBuilder builder = relBuilder().scan("EMP");
> final RexNode condition =
> builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
> builder.literal(20), builder.literal(30));
> final RelNode root = relBuilder().scan("EMP").filter(condition).build();
> final String sql = toSql(root);
> final String expectedSql = "SELECT *\n"
> + "FROM \"scott\".\"EMP\"\n"
> + "WHERE \"DEPTNO\" NOT IN (20, 30)";
> assertThat(sql, isLinux(expectedSql));
> }
> {code}
> Above test fails with error:
> {code:java}
> Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
> 30)"
> but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
> 30"
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3242) RelToSqlConverter not handling "NOT IN" properly
Atharv Rajput created CALCITE-3242:
--
Summary: RelToSqlConverter not handling "NOT IN" properly
Key: CALCITE-3242
URL: https://issues.apache.org/jira/browse/CALCITE-3242
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Atharv Rajput
Assignee: Atharv Rajput
Fix For: 1.21.0
When RelNode is having `NOT IN` operator, it's being converted incorrectly by
RelToSqlConverter. For example
{code:java}
@Test public void testNotInOperator() {
final RelBuilder builder = relBuilder().scan("EMP");
final RexNode condition =
builder.call(SqlStdOperatorTable.NOT_IN, builder.field("DEPTNO"),
builder.literal(20), builder.literal(30));
final RelNode root = relBuilder().scan("EMP").filter(condition).build();
final String sql = toSql(root);
final String expectedSql = "SELECT *\n"
+ "FROM \"scott\".\"EMP\"\n"
+ "WHERE \"DEPTNO\" NOT IN (20, 30)";
assertThat(sql, isLinux(expectedSql));
}
{code}
Above test fails with error:
{code:java}
Expected: is "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN (20,
30)"
but: was "SELECT *\nFROM \"scott\".\"EMP\"\nWHERE \"DEPTNO\" NOT IN 20 NOT IN
30"
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
