[jira] [Comment Edited] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

[Danny Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824786#comment-16824786
 ] 

Danny Chan edited comment on CALCITE-2282 at 4/24/19 3:50 AM:
--

[~julianhyde] We did have an identifier in sql call[1], now we have the 
function qualifier, the parse position and the operands, but the question is we 
do not know how to unparse the call if we don't know which kind of call it is, 
like a VALUES operator or a CASE WHEN operator, they have special function 
formula and not the common like "func(operand1, operand2)".

Like a case when clause would be unparsed to:
{code:java}
SELECT (CASE WHEN (1 > 0) THEN TRUE ELSE FALSE END), `EMPNO`
FROM `EMP`
HAVING (`COUNT`(*) > 5)
{code}
[1] 
[https://github.com/apache/calcite/blob/986a2d579c8f9b9f08aa9bbbfe11efc4e7bb0809/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L411]


was (Author: danny0405):
[~julianhyde] We did have an identifier in sql call[1], now we have the 
function qualifier, the parse position and the operands, but the question is we 
do not know how to unparse the call if we don't know which kind of call it is, 
like a VALUES operator or a CASE WHEN operator, they have special function 
formula and not the common like "func(operand1, operand2)".

 

[1] 
https://github.com/apache/calcite/blob/986a2d579c8f9b9f08aa9bbbfe11efc4e7bb0809/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L411

> Allow OperatorTable to be pluggable in the parser
> -
>
> Key: CALCITE-2282
> URL: https://issues.apache.org/jira/browse/CALCITE-2282
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Sudheesh Katkam
>Priority: Major
> Attachments: CALCITE-2282.patch.txt
>
>
> SqlAbstractParserImpl [hardcodes OperatorTable to 
> SqlStdOperatorTable|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334].
>  Make this pluggable via a protected method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

[Danny Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824786#comment-16824786
 ] 

Danny Chan commented on CALCITE-2282:
-

[~julianhyde] We did have an identifier in sql call[1], now we have the 
function qualifier, the parse position and the operands, but the question is we 
do not know how to unparse the call if we don't know which kind of call it is, 
like a VALUES operator or a CASE WHEN operator, they have special function 
formula and not the common like "func(operand1, operand2)".

 

[1] 
https://github.com/apache/calcite/blob/986a2d579c8f9b9f08aa9bbbfe11efc4e7bb0809/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L411

> Allow OperatorTable to be pluggable in the parser
> -
>
> Key: CALCITE-2282
> URL: https://issues.apache.org/jira/browse/CALCITE-2282
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Sudheesh Katkam
>Priority: Major
> Attachments: CALCITE-2282.patch.txt
>
>
> SqlAbstractParserImpl [hardcodes OperatorTable to 
> SqlStdOperatorTable|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334].
>  Make this pluggable via a protected method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2453) Enhance the SQL parser in order to optionally support semicolon at the end of the sql statements

[Julian Hyde (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Hyde resolved CALCITE-2453.
--
   Resolution: Fixed
Fix Version/s: 1.20.0

Fixed in 
[986a2d579c8f9b9f08aa9bbbfe11efc4e7bb0809|https://github.com/apache/calcite/commit/986a2d579c8f9b9f08aa9bbbfe11efc4e7bb0809].
 Thanks for the PR, [~Chunwei Lei] and [~charbel]!

> Enhance the SQL parser in order to optionally support semicolon at the end of 
> the sql statements
> 
>
> Key: CALCITE-2453
> URL: https://issues.apache.org/jira/browse/CALCITE-2453
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: next
>Reporter: charbel yazbeck
>Assignee: Chunwei Lei
>Priority: Trivial
>  Labels: pull-request-available
> Fix For: 1.20.0
>
> Attachments: 
> 0001-CALCITE-2453-Allowing-SQL-statements-to-optionally-e.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Consists of adding [] in Parser.jj



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION

[Rong Rong (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824753#comment-16824753
 ] 

Rong Rong commented on CALCITE-2721:


Thanks [~julianhyde] for the clarification :-)

> Support parsing of DOT + MEMBER_FUNCTION
> 
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Rong Rong
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
> Attachments: 6_17_Method_invocation.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Support parsing of  +  parsing Similar to 
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member 
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824704#comment-16824704
 ] 

Julian Hyde commented on CALCITE-2721:
--

I think [~zabetak] wants to get this into release 1.20. We know that it is not 
fixed yet. I need to review.

> Support parsing of DOT + MEMBER_FUNCTION
> 
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Rong Rong
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
> Attachments: 6_17_Method_invocation.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Support parsing of  +  parsing Similar to 
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member 
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3008) Making AuxiliaryConverter Pluggable

[Rong Rong (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824684#comment-16824684
 ] 

Rong Rong commented on CALCITE-3008:


Yeah, I think I am not explaining clearly . I mean create a {{RexConvertlet}} 
interface, similar to {{RelSqlConvertlet}} 

This interface should be generic enough to handle any operator->operator (e.g. 
Rex->Rex) conversion, 
the impl of this will only have one for auxiliaryconverter (and will be put in 
the {{StandardConvertletTable}}).

> Making AuxiliaryConverter Pluggable
> ---
>
> Key: CALCITE-3008
> URL: https://issues.apache.org/jira/browse/CALCITE-3008
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Rong Rong
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently the {{AuxiliaryConverter}} in calcite core is set to be static with 
> only one basic implementation. It would be nice to have it pluggable so that 
> other systems can implement its own. 
> Was wondering if this would be a good feature to add? 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION

[Rong Rong (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824668#comment-16824668
 ] 

Rong Rong commented on CALCITE-2721:


[~zabetak] not sure this has been fixed in 1.20, should I revert the change? 
has this PR been merged?

> Support parsing of DOT + MEMBER_FUNCTION
> 
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Rong Rong
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
> Attachments: 6_17_Method_invocation.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Support parsing of  +  parsing Similar to 
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member 
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CALCITE-2913) add a KafkaAdapter for Stream

[Haisheng Yuan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Haisheng Yuan reassigned CALCITE-2913:
--

Assignee: (was: James Xu)

> add a KafkaAdapter for Stream
> -
>
> Key: CALCITE-2913
> URL: https://issues.apache.org/jira/browse/CALCITE-2913
> Project: Calcite
>  Issue Type: New Feature
>  Components: core
>Reporter: Xu Mingmin
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Add a new adapter which exposes a Kafka topic into a Stream table, we've one 
> version in our env and would like to share it if not duplicated.
> Hint, we are actually extending it as a batch table, limiting to Stream table 
> sounds more straight-forward to me as 1st step.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-3004) RexOver is incorrectly pushed down in ProjectSetOpTransposeRule and ProjectCorrelateTransposeRule

[Haisheng Yuan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Haisheng Yuan resolved CALCITE-3004.

   Resolution: Fixed
Fix Version/s: 1.20.0

Fixed in commit 
https://github.com/apache/calcite/commit/f26d92f956c4f8b59bafbf7cfc7431f3d4d536f9,
 thanks for the PR, [~Chunwei Lei]!

> RexOver is incorrectly pushed down in ProjectSetOpTransposeRule and 
> ProjectCorrelateTransposeRule
> -
>
> Key: CALCITE-3004
> URL: https://issues.apache.org/jira/browse/CALCITE-3004
> Project: Calcite
>  Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Hongze Zhang
>Assignee: Chunwei Lei
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> *1. Test case for ProjectSetOpTransposeRule:*
> {code:sql}
> select count(sal) over () from (select * from emp e1 union all select * from 
> emp e2)
> {code}
> Plan:
> {code:java}
> LogicalUnion(all=[true])
>   LogicalProject(EXPR$0=[COUNT($5) OVER (RANGE BETWEEN UNBOUNDED PRECEDING 
> AND UNBOUNDED FOLLOWING)])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
>   LogicalProject(EXPR$0=[COUNT($5) OVER (RANGE BETWEEN UNBOUNDED PRECEDING 
> AND UNBOUNDED FOLLOWING)])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> Should be:
> {code:java}
> LogicalProject(EXPR$0=[COUNT($5) OVER (RANGE BETWEEN UNBOUNDED PRECEDING AND 
> UNBOUNDED FOLLOWING)])
>   LogicalUnion(all=[true])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4], 
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8])
>   LogicalTableScan(table=[[CATALOG, SALES, EMP]]){code}
>  
> *2. Test case for ProjectCorrelateTransposeRule:*
> {code:sql}
> select t2.empno, sum(t1.deptno) over () from DEPT_NESTED as t1, 
> unnest(t1.employees) as t2
> {code}
> *Plan: Will cause infinitely loop due to RexOver is pushed down*
> Should be:
>  
> {code:java}
> LogicalProject(EMPNO=[$2], EXPR$1=[SUM($0) OVER (RANGE BETWEEN UNBOUNDED 
> PRECEDING AND UNBOUNDED FOLLOWING)])
>   LogicalCorrelate(correlation=[$cor1], joinType=[inner], 
> requiredColumns=[{1}])
> LogicalProject(DEPTNO=[$0], EMPLOYEES=[$3])
>   LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
>   LogicalProject(EMPNO=[$0])
> Uncollect
>   LogicalProject(EMPLOYEES=[$cor1.EMPLOYEES])
> LogicalValues(tuples=[[{ 0 }]]){code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3001) Upgrade to Apache Druid 0.14.0-incubating

[Nishant Bangarwa (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824428#comment-16824428
 ] 

Nishant Bangarwa commented on CALCITE-3001:
---

[~jcamachorodriguez] Thanks for the review.

> Upgrade to Apache Druid 0.14.0-incubating
> -
>
> Key: CALCITE-3001
> URL: https://issues.apache.org/jira/browse/CALCITE-3001
> Project: Calcite
>  Issue Type: Task
>  Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Apache Druid 0.14.0-incubating has been released. 
> This task is to upgrade the test vm to use Apache Druid 0.14.0-incubating and 
> update calcite docs accordingly. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824425#comment-16824425
 ] 

Julian Hyde commented on CALCITE-2282:
--

Good analysis - thanks. Does the un-validated {{SqlOperator}} still have access 
to the identifier that created it? If so, can we use 
{{SqlParserPos.isQuoted()}} and use that during unparse? As long as we're 
unparsing for the same dialect that we parsed, the built-in functions and 
reserved keywords will be the same, so we'll be OK.

> Allow OperatorTable to be pluggable in the parser
> -
>
> Key: CALCITE-2282
> URL: https://issues.apache.org/jira/browse/CALCITE-2282
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Sudheesh Katkam
>Priority: Major
> Attachments: CALCITE-2282.patch.txt
>
>
> SqlAbstractParserImpl [hardcodes OperatorTable to 
> SqlStdOperatorTable|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334].
>  Make this pluggable via a protected method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Egor Ryashin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824397#comment-16824397
 ] 

Egor Ryashin commented on CALCITE-3002:
---

[~julianhyde] sorry, I was sure I tried exactly that in PostgreSQL, but I have 
the error right now in PostgreSQL 11.2:
{code:java}
select (case empno when empno > 1 then 1 else empno end) fro...
   ^
HINT:  No operator matches the given name and argument types. You might need to 
add explicit type casts.
{code}
Thanks for the help

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused 
> by: java.sql.SQLException: Error while executing SQL "select (case empno when 
> empno > 1 then 1 else empno end) from emps": From line 1, column 9 to line 1, 
> column 55: Cannot apply '=' to arguments of type ' = '. 
> Supported form(s): ' = ' at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
>  at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
>  at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:358) at 
> org.apache.calcite.test.CsvTest.access$300(CsvTest.java:67) at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1018) ... 28 more 
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, 
> column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 

[jira] [Resolved] (CALCITE-3011) Support left and right outer joins with AggregateJoinTransposeRule

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-3011.
--
   Resolution: Fixed
Fix Version/s: 1.20.0

Fixed in 
[ecb469b9fd6122e7597cca93741ec34085b35ab4|https://github.com/apache/calcite/commit/ecb469b9fd6122e7597cca93741ec34085b35ab4]
 (btw, fixed a typo and use Javadoc for comments when I merged). Thanks [~vgarg]

> Support left and right outer joins with AggregateJoinTransposeRule
> --
>
> Key: CALCITE-3011
> URL: https://issues.apache.org/jira/browse/CALCITE-3011
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Vineet Garg
>Assignee: Vineet Garg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Currently {{AggregateJoinTransposeRule}} only support INNER join. Aggregates 
> (at least the ones without aggregate functions) could be pushed through OUTER 
> joins with current logic.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-3011) Support left and right outer joins with AggregateJoinTransposeRule

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez updated CALCITE-3011:
-
Summary: Support left and right outer joins with AggregateJoinTransposeRule 
 (was: Support outer joins with AggregateJoinTransposeRule)

> Support left and right outer joins with AggregateJoinTransposeRule
> --
>
> Key: CALCITE-3011
> URL: https://issues.apache.org/jira/browse/CALCITE-3011
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Vineet Garg
>Assignee: Vineet Garg
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Currently {{AggregateJoinTransposeRule}} only support INNER join. Aggregates 
> (at least the ones without aggregate functions) could be pushed through OUTER 
> joins with current logic.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Julian Hyde (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824346#comment-16824346
 ] 

Julian Hyde commented on CALCITE-3002:
--

[~egrs] Did you really run it on PostgreSQL? If so, which version did you use, 
and what SQL did you use? Here's what happened for me; you can try it on 
[rextester|https://rextester.com/l/postgresql_online_compiler]:
{code:java}
drop table if exists emps;
create table emps(empno int);
select (case empno when empno > 1 then 1 else empno end) from emps;
42883: operator does not exist: integer = boolean
{code}
I know why the query succeeds on MySQL: it allows boolean to be treated as 
integer. But then MySQL sucks.

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused 
> by: java.sql.SQLException: Error while executing SQL "select (case empno when 
> empno > 1 then 1 else empno end) from emps": From line 1, column 9 to line 1, 
> column 55: Cannot apply '=' to arguments of type ' = '. 
> Supported form(s): ' = ' at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
>  at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
>  at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:358) at 
> org.apache.calcite.test.CsvTest.access$300(CsvTest.java:67) at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1018) ... 28 more 
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, 
> column 9 to line 1, column 5

[jira] [Resolved] (CALCITE-3001) Upgrade to Apache Druid 0.14.0-incubating

[Jesus Camacho Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesus Camacho Rodriguez resolved CALCITE-3001.
--
   Resolution: Fixed
Fix Version/s: 1.20.0

Fixed in 
[898ddbd8388ed28066a598297d82121557dde7d7|https://github.com/apache/calcite/commit/898ddbd8388ed28066a598297d82121557dde7d7].
 Thanks [~nishantbangarwa]

> Upgrade to Apache Druid 0.14.0-incubating
> -
>
> Key: CALCITE-3001
> URL: https://issues.apache.org/jira/browse/CALCITE-3001
> Project: Calcite
>  Issue Type: Task
>  Components: druid
>Reporter: Nishant Bangarwa
>Assignee: Nishant Bangarwa
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Apache Druid 0.14.0-incubating has been released. 
> This task is to upgrade the test vm to use Apache Druid 0.14.0-incubating and 
> update calcite docs accordingly. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-2993) ParseException may be thrown for legal SQL queries due to incorrect "LOOKAHEAD(1)" hints

[Hongze Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongze Zhang resolved CALCITE-2993.
---
Resolution: Fixed

Fixed in 
[577e72cb95e5d4d88f187909c14d8691c266ac4c|https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=577e72cb95e5d4d88f187909c14d8691c266ac4c].
 Thanks for the review, [~Chunwei Lei]!

> ParseException may be thrown for legal SQL queries due to incorrect 
> "LOOKAHEAD(1)" hints
> 
>
> Key: CALCITE-2993
> URL: https://issues.apache.org/jira/browse/CALCITE-2993
> Project: Calcite
>  Issue Type: Bug
>Reporter: Hongze Zhang
>Assignee: Hongze Zhang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> In some cases, ParseException is thrown incorrectly:
> Case 1
> {code:sql}
> select lead(x) ignore from t -- "ignore" aliases "lead(x)"
> {code}
> Case 2
> {code:sql}
> select *
>   from t match_recognize
>   (
>  after match skip to last -- "last" is a identifier. This is the implicit 
> form of "skip to last last"
> pattern (strt down+ up+)
> define
>   down as down.price < PREV(down.price),
>   up as up.price > prev(up.price)
>   ) mr
> {code}
> Case 3
> {code:sql}
> select json_object(key: value) from t -- "key"/"value" are both column names.
> {code}
> And the failure on Case 1 is introduced by the fix of CALCITE-2847, Case 2/3 
> are not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2889) IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods with varargs

[Rui Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824232#comment-16824232
 ] 

Rui Wang commented on CALCITE-2889:
---

[~zabetak]

Las time, I couldn't add tests to UdfTest (something does not work for me). 

I could address your two comments today but I am afraid that I don't have 
bandwidth to figure out and fix UdfTest. 

> IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods 
> with varargs
> --
>
> Key: CALCITE-2889
> URL: https://issues.apache.org/jira/browse/CALCITE-2889
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Rui Wang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumUtils.java#L210
> If "targetTypes" is from "method.getParameterTypes()" and if method's 
> signature is "func(stirng ... args)", then "targetTypes" will contain one 
> type "String[].class", but "expressions" could contain one than one element, 
> so it throws IndexOutOfBoundsException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-2889) IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods with varargs

[Rui Wang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824232#comment-16824232
 ] 

Rui Wang edited comment on CALCITE-2889 at 4/23/19 3:17 PM:


[~zabetak]

Las time, I couldn't add tests to UdfTest (something did not work for me). 

I could address your two comments today but I am afraid that I don't have 
bandwidth to figure out and fix UdfTest. 


was (Author: amaliujia):
[~zabetak]

Las time, I couldn't add tests to UdfTest (something does not work for me). 

I could address your two comments today but I am afraid that I don't have 
bandwidth to figure out and fix UdfTest. 

> IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods 
> with varargs
> --
>
> Key: CALCITE-2889
> URL: https://issues.apache.org/jira/browse/CALCITE-2889
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Rui Wang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumUtils.java#L210
> If "targetTypes" is from "method.getParameterTypes()" and if method's 
> signature is "func(stirng ... args)", then "targetTypes" will contain one 
> type "String[].class", but "expressions" could contain one than one element, 
> so it throws IndexOutOfBoundsException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2721) Support parsing of DOT + MEMBER_FUNCTION

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis updated CALCITE-2721:
-
Fix Version/s: 1.20.0

> Support parsing of DOT + MEMBER_FUNCTION
> 
>
> Key: CALCITE-2721
> URL: https://issues.apache.org/jira/browse/CALCITE-2721
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Reporter: Rong Rong
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
> Attachments: 6_17_Method_invocation.png
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Support parsing of  +  parsing Similar to 
> {panel:title=Example}
> {{SELECT t.complex_col}}*{{.member_func()}}* {{FROM tbl;}}
> {panel}
> For more details please see: [Member 
> Function|https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_8001.htm#i2126584]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis reassigned CALCITE-2624:


Assignee: Khawla Mouhoubi  (was: Stamatis Zampetakis)

> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Khawla Mouhoubi
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many types of join 
> operators. However, in many cases, it is possible and beneficial for 
> optimization purposes to just push the sort without the limit and offset. 
> Since we do not know in advance if the join operator preserves the order we 
> cannot remove (that is why I am saying copy and not transpose) the sort 
> operator on top of the join. The latter is not really a problem since the 
> SortRemoveRule can detect such cases and remove the sort if it is redundant.
> A few concrete examples where this optimization makes sense are outlined 
> below:
>  * allow the sort to be later absorbed by an index scan and disappear from 
> the plan (Sort + Tablescan => IndexScan with RelCollation);
>  * allow operators that require sorted inputs to be exploited more easily 
> (e.g., merge join);
>  * allow the sort to be performed on a possibly smaller result (assuming that 
> the physical binary operator that is going to be used preserves the order of 
> left/right input and the top sort operator can be removed entirely).
> I propose to add a new rule (e.g., SortCopyBelowJoinRule, 
> SortJoinCopyBelowRule) which allows a sort to be copied to the left or right 
> (or to both if it is rather easy to decompose the sort) of a join operator 
> (excluding the limit and offset attributes) if the respective inputs are not 
> already sorted. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis reassigned CALCITE-2624:


Assignee: Stamatis Zampetakis  (was: Khawla Mouhoubi)

> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many types of join 
> operators. However, in many cases, it is possible and beneficial for 
> optimization purposes to just push the sort without the limit and offset. 
> Since we do not know in advance if the join operator preserves the order we 
> cannot remove (that is why I am saying copy and not transpose) the sort 
> operator on top of the join. The latter is not really a problem since the 
> SortRemoveRule can detect such cases and remove the sort if it is redundant.
> A few concrete examples where this optimization makes sense are outlined 
> below:
>  * allow the sort to be later absorbed by an index scan and disappear from 
> the plan (Sort + Tablescan => IndexScan with RelCollation);
>  * allow operators that require sorted inputs to be exploited more easily 
> (e.g., merge join);
>  * allow the sort to be performed on a possibly smaller result (assuming that 
> the physical binary operator that is going to be used preserves the order of 
> left/right input and the top sort operator can be removed entirely).
> I propose to add a new rule (e.g., SortCopyBelowJoinRule, 
> SortJoinCopyBelowRule) which allows a sort to be copied to the left or right 
> (or to both if it is rather easy to decompose the sort) of a join operator 
> (excluding the limit and offset attributes) if the respective inputs are not 
> already sorted. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824125#comment-16824125
 ] 

Stamatis Zampetakis commented on CALCITE-2624:
--

I changed a bit the summary and description of the issue to focus on joins. As 
Julian said, if it makes sense we can try to generalize the rule afterwards.

> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Khawla Mouhoubi
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many types of join 
> operators. However, in many cases, it is possible and beneficial for 
> optimization purposes to just push the sort without the limit and offset. 
> Since we do not know in advance if the join operator preserves the order we 
> cannot remove (that is why I am saying copy and not transpose) the sort 
> operator on top of the join. The latter is not really a problem since the 
> SortRemoveRule can detect such cases and remove the sort if it is redundant.
> A few concrete examples where this optimization makes sense are outlined 
> below:
>  * allow the sort to be later absorbed by an index scan and disappear from 
> the plan (Sort + Tablescan => IndexScan with RelCollation);
>  * allow operators that require sorted inputs to be exploited more easily 
> (e.g., merge join);
>  * allow the sort to be performed on a possibly smaller result (assuming that 
> the physical binary operator that is going to be used preserves the order of 
> left/right input and the top sort operator can be removed entirely).
> I propose to add a new rule (e.g., SortCopyBelowJoinRule, 
> SortJoinCopyBelowRule) which allows a sort to be copied to the left or right 
> (or to both if it is rather easy to decompose the sort) of a join operator 
> (excluding the limit and offset attributes) if the respective inputs are not 
> already sorted. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis reassigned CALCITE-2624:


Assignee: Khawla Mouhoubi

> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Assignee: Khawla Mouhoubi
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many types of join 
> operators. However, in many cases, it is possible and beneficial for 
> optimization purposes to just push the sort without the limit and offset. 
> Since we do not know in advance if the join operator preserves the order we 
> cannot remove (that is why I am saying copy and not transpose) the sort 
> operator on top of the join. The latter is not really a problem since the 
> SortRemoveRule can detect such cases and remove the sort if it is redundant.
> A few concrete examples where this optimization makes sense are outlined 
> below:
>  * allow the sort to be later absorbed by an index scan and disappear from 
> the plan (Sort + Tablescan => IndexScan with RelCollation);
>  * allow operators that require sorted inputs to be exploited more easily 
> (e.g., merge join);
>  * allow the sort to be performed on a possibly smaller result (assuming that 
> the physical binary operator that is going to be used preserves the order of 
> left/right input and the top sort operator can be removed entirely).
> I propose to add a new rule (e.g., SortCopyBelowJoinRule, 
> SortJoinCopyBelowRule) which allows a sort to be copied to the left or right 
> (or to both if it is rather easy to decompose the sort) of a join operator 
> (excluding the limit and offset attributes) if the respective inputs are not 
> already sorted. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis updated CALCITE-2624:
-
Description: 
Currently, the only rule that allows a sort to traverse a binary operator is 
the SortJoinTransposeRule. The rule was introduced mainly to push limits in the 
case of left and right outer joins (see CALCITE-831).

I assume that the main reason that we don't have more rules is that sorts with 
limits and offsets cannot be pushed safely below many types of join operators. 
However, in many cases, it is possible and beneficial for optimization purposes 
to just push the sort without the limit and offset. Since we do not know in 
advance if the join operator preserves the order we cannot remove (that is why 
I am saying copy and not transpose) the sort operator on top of the join. The 
latter is not really a problem since the SortRemoveRule can detect such cases 
and remove the sort if it is redundant.

A few concrete examples where this optimization makes sense are outlined below:
 * allow the sort to be later absorbed by an index scan and disappear from the 
plan (Sort + Tablescan => IndexScan with RelCollation);
 * allow operators that require sorted inputs to be exploited more easily 
(e.g., merge join);
 * allow the sort to be performed on a possibly smaller result (assuming that 
the physical binary operator that is going to be used preserves the order of 
left/right input and the top sort operator can be removed entirely).

I propose to add a new rule (e.g., SortCopyBelowJoinRule, 
SortJoinCopyBelowRule) which allows a sort to be copied to the left or right 
(or to both if it is rather easy to decompose the sort) of a join operator 
(excluding the limit and offset attributes) if the respective inputs are not 
already sorted. 

  was:
Currently, the only rule that allows a sort to traverse a binary operator is 
the SortJoinTransposeRule. The rule was introduced mainly to push limits in the 
case of left and right outer joins (see CALCITE-831).

I assume that the main reason that we don't have more rules is that sorts with 
limits and offsets cannot be pushed safely below many binary operators. 
However, in many cases, it is possible and beneficial for optimization purposes 
to just push the sort (without the limit and offset) below the binary operator. 
Since we do not know in advance if the binary operator preserves the sort we 
cannot remove (that is why I am saying copy and not transpose) the sort 
operator on top of the binary operator. The latter is not really a problem 
since the SortRemoveRule can detect such cases and remove the sort if it is 
redundant.

A few concrete examples where this optimization makes sense are outlined below:
 * allow the sort to be later absorbed by an index scan and disappear from the 
plan (Sort + Tablescan => IndexScan with RelCollation);
 * allow operators that require sorted inputs to be exploited more easily 
(e.g., merge join);
 * allow the sort to be performed on a possibly smaller result (assuming that 
the physical binary operator that is going to be used preserves the order of 
left/right input and the top sort operator can be removed entirely).

I propose to add a new rule (e.g., SortCopyBelowBiRelRule, 
SortBiRelCopyBelowRule, SortBiRelTransposeRule) which allows a sort to be 
copied to the left or right of a BiRel operator (excluding the limit and offset 
attributes) if the respective input is not already sorted. For my use case, it 
would suffice to apply the rule only on joins and correlates but I don't see 
why not making it a bit more general from the beginning.


> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many types of join 
> operators. However, in many cases, it is possible and beneficial for 
> optimization purposes to just push the sort without the limit and offset. 
> Since we do not know in advance if the join operator preserves the order we 
> cannot remove (that is why I am saying copy and not transpose) the sort 
> operator on top of the join. The latter is not really a problem since the 
> SortRemoveRule can detect such cases and remove the sort if it is redundant.
> A few concrete examples where this optimiz

[jira] [Comment Edited] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Hongze Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823960#comment-16823960
 ] 

Hongze Zhang edited comment on CALCITE-3002 at 4/23/19 1:02 PM:


I probably missed something, but the case looks to be straightforward.
 [~egrs] - I think basically the below case expression:
{code:sql}
case empno when empno > 1 then 1 else empno end
{code}
is equivalent to:
{code:sql}
case when empno = (empno > 1) then 1 else empno end
{code}
In current version of Calcite, the comparison predicate (EQUALS, GREATER THAN, 
LESS THAN, etc.) are validated based on assumption that the operands are in the 
same SQL type family[1]. Maybe some other SQL implementations use looser 
strategies but Calcite is not able to do that so far (And maybe there are other 
JIRAs such as CALCITE-2302 suggesting loose strategies but I am not sure if the 
related changes could be brought into Calcite soon enough).

[1] 
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/type/SqlTypeFamily.java]


was (Author: zhztheplayer):
I probably missed something, but the case looks to be straightforward.
[~egrs] - I think basically the below case expression:
{code:sql}
case empno when empno > 1 then 1 else empno end
{code}
is equivalent to:
{code:sql}
case when empno = (empno > 1) then 1 else empno end
{code}
In current version of Calcite, the comparison predicate (EQUALS, GREATER THAN, 
LESS THAN, etc.) are validated based on assumption that the operands are in the 
same SQL type family[1]. Maybe some other SQL implementations use some looser 
strategies but Calcite is not able to do that so far (And maybe there are some 
other JIRAs such as CALCITE-2302 suggesting loose strategies but I am not sure 
if the related changes could be bring into Calcite soon enough).

[1] 
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/type/SqlTypeFamily.java

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70

[jira] [Updated] (CALCITE-2624) Add a rule to copy a sort below a join operator

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis updated CALCITE-2624:
-
Summary: Add a rule to copy a sort below a join operator  (was: Add a rule 
to copy a sort below a binary operator over the left or right input)

> Add a rule to copy a sort below a join operator
> ---
>
> Key: CALCITE-2624
> URL: https://issues.apache.org/jira/browse/CALCITE-2624
> Project: Calcite
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.17.0
>Reporter: Stamatis Zampetakis
>Priority: Major
>
> Currently, the only rule that allows a sort to traverse a binary operator is 
> the SortJoinTransposeRule. The rule was introduced mainly to push limits in 
> the case of left and right outer joins (see CALCITE-831).
> I assume that the main reason that we don't have more rules is that sorts 
> with limits and offsets cannot be pushed safely below many binary operators. 
> However, in many cases, it is possible and beneficial for optimization 
> purposes to just push the sort (without the limit and offset) below the 
> binary operator. Since we do not know in advance if the binary operator 
> preserves the sort we cannot remove (that is why I am saying copy and not 
> transpose) the sort operator on top of the binary operator. The latter is not 
> really a problem since the SortRemoveRule can detect such cases and remove 
> the sort if it is redundant.
> A few concrete examples where this optimization makes sense are outlined 
> below:
>  * allow the sort to be later absorbed by an index scan and disappear from 
> the plan (Sort + Tablescan => IndexScan with RelCollation);
>  * allow operators that require sorted inputs to be exploited more easily 
> (e.g., merge join);
>  * allow the sort to be performed on a possibly smaller result (assuming that 
> the physical binary operator that is going to be used preserves the order of 
> left/right input and the top sort operator can be removed entirely).
> I propose to add a new rule (e.g., SortCopyBelowBiRelRule, 
> SortBiRelCopyBelowRule, SortBiRelTransposeRule) which allows a sort to be 
> copied to the left or right of a BiRel operator (excluding the limit and 
> offset attributes) if the respective input is not already sorted. For my use 
> case, it would suffice to apply the rule only on joins and correlates but I 
> don't see why not making it a bit more general from the beginning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (CALCITE-3015) Add rule to remove constants in group keys

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis resolved CALCITE-3015.
--
   Resolution: Duplicate
Fix Version/s: 1.20.0

I am marking this as resolved (and duplicate), rather than closed since I think 
closed is reserved for release time. 

> Add rule to remove constants in group keys
> --
>
> Key: CALCITE-3015
> URL: https://issues.apache.org/jira/browse/CALCITE-3015
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Fix For: 1.20.0
>
>
> Constants in group keys can be removed to reduce shuffle. For instance, 
>  
> {code:java}
> select key, count(*) from (select 1 as key from src) dual group by key;
> {code}
> can be reduced to
> {code:java}
> select count(*) from (select 1 as key from src) dual;{code}
> It could save much resource in distribute system if all group keys are 
> constants since the distribution becomes {{SINGLETON}} instead of {{HASH}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (CALCITE-3015) Add rule to remove constants in group keys

[Stamatis Zampetakis (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CALCITE-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stamatis Zampetakis reopened CALCITE-3015:
--

> Add rule to remove constants in group keys
> --
>
> Key: CALCITE-3015
> URL: https://issues.apache.org/jira/browse/CALCITE-3015
> Project: Calcite
>  Issue Type: Improvement
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
>
> Constants in group keys can be removed to reduce shuffle. For instance, 
>  
> {code:java}
> select key, count(*) from (select 1 as key from src) dual group by key;
> {code}
> can be reduced to
> {code:java}
> select count(*) from (select 1 as key from src) dual;{code}
> It could save much resource in distribute system if all group keys are 
> constants since the distribution becomes {{SINGLETON}} instead of {{HASH}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3013) support CeilFuncBigInt TO

[Stamatis Zampetakis (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823965#comment-16823965
 ] 

Stamatis Zampetakis commented on CALCITE-3013:
--

Hey [~xzh_dz], can you clarify what you would like to do and why you closed 
this issue? Even if there is no need to do anything the description of the JIRA 
and the resolution status might be useful for other people.

> support CeilFuncBigInt  TO 
> --
>
> Key: CALCITE-3013
> URL: https://issues.apache.org/jira/browse/CALCITE-3013
> Project: Calcite
>  Issue Type: Test
>Reporter: xzh_dz
>Priority: Trivial
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Hongze Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823960#comment-16823960
 ] 

Hongze Zhang commented on CALCITE-3002:
---

I probably missed something, but the case looks to be straightforward.
[~egrs] - I think basically the below case expression:
{code:sql}
case empno when empno > 1 then 1 else empno end
{code}
is equivalent to:
{code:sql}
case when empno = (empno > 1) then 1 else empno end
{code}
In current version of Calcite, the comparison predicate (EQUALS, GREATER THAN, 
LESS THAN, etc.) are validated based on assumption that the operands are in the 
same SQL type family[1]. Maybe some other SQL implementations use some looser 
strategies but Calcite is not able to do that so far (And maybe there are some 
other JIRAs such as CALCITE-2302 suggesting loose strategies but I am not sure 
if the related changes could be bring into Calcite soon enough).

[1] 
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/type/SqlTypeFamily.java

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused 
> by: java.sql.SQLException: Error while executing SQL "select (case empno when 
> empno > 1 then 1 else empno end) from emps": From line 1, column 9 to line 1, 
> column 55: Cannot apply '=' to arguments of type ' = '. 
> Supported form(s): ' = ' at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
>  at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(A

[jira] [Commented] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Egor Ryashin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823945#comment-16823945
 ] 

Egor Ryashin commented on CALCITE-3002:
---

I see according to specification 92 the statement is actually incorrect, I 
still wonder why it works in SQL DBs.

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused 
> by: java.sql.SQLException: Error while executing SQL "select (case empno when 
> empno > 1 then 1 else empno end) from emps": From line 1, column 9 to line 1, 
> column 55: Cannot apply '=' to arguments of type ' = '. 
> Supported form(s): ' = ' at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
>  at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
>  at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:358) at 
> org.apache.calcite.test.CsvTest.access$300(CsvTest.java:67) at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1018) ... 28 more 
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, 
> column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' 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.new

[jira] [Commented] (CALCITE-3002) Case statement fails with: SqlValidatorException: Cannot apply '=' to arguments of type ' = '.

[Egor Ryashin (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823907#comment-16823907
 ] 

Egor Ryashin commented on CALCITE-3002:
---

That's not the right clause, __ is used by that query and 
__ has a boolean result correctly.

>From the specification:
{quote} ::= WHEN  THEN 

 ::= WHEN  THEN 
{quote}
I use that query in *MySQL* and checked it in *PostgreSQL* too.

> Case statement fails with: SqlValidatorException: Cannot apply '=' to 
> arguments of type ' = '.
> 
>
> Key: CALCITE-3002
> URL: https://issues.apache.org/jira/browse/CALCITE-3002
> Project: Calcite
>  Issue Type: Bug
>  Components: csv-adapter, druid
>Affects Versions: 1.19.0
>Reporter: Egor Ryashin
>Priority: Major
> Fix For: 1.20.0
>
> Attachments: image-2019-04-23-00-29-31-703.png
>
>
> Query like
> {code:java}
> select (case empno when empno > 1 then 1 else empno end) from emps{code}
> produces an error:
> {code}
> java.lang.RuntimeException: java.sql.SQLException: Error while executing SQL 
> "select (case empno when empno > 1 then 1 else empno end) from emps": From 
> line 1, column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1021) at 
> org.apache.calcite.test.CsvTest.testSelectSingleProjectCase(CsvTest.java:188) 
> 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:51)
>  at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
>  at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) Caused 
> by: java.sql.SQLException: Error while executing SQL "select (case empno when 
> empno > 1 then 1 else empno end) from emps": From line 1, column 9 to line 1, 
> column 55: Cannot apply '=' to arguments of type ' = '. 
> Supported form(s): ' = ' at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:56) at 
> org.apache.calcite.avatica.Helper.createException(Helper.java:41) at 
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
>  at 
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
>  at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:358) at 
> org.apache.calcite.test.CsvTest.access$300(CsvTest.java:67) at 
> org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1018) ... 28 more 
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, 
> column 9 to line 1, column 55: Cannot apply '=' to arguments of type 
> ' = '. Supported form(s): ' = 
> ' at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>  at 
> sun.reflect.Delegati

[jira] [Commented] (CALCITE-2889) IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods with varargs

[Stamatis Zampetakis (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823899#comment-16823899
 ] 

Stamatis Zampetakis commented on CALCITE-2889:
--

[~julianhyde] sure I will try! 

Hey [~amaliujia] did you have a chance to look the comments in the PR? 

> IndexOutOfBoundsException in EnumUtils#fromInternal when handling methods 
> with varargs
> --
>
> Key: CALCITE-2889
> URL: https://issues.apache.org/jira/browse/CALCITE-2889
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Rui Wang
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.20.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumUtils.java#L210
> If "targetTypes" is from "method.getParameterTypes()" and if method's 
> signature is "func(stirng ... args)", then "targetTypes" will contain one 
> type "String[].class", but "expressions" could contain one than one element, 
> so it throws IndexOutOfBoundsException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

[Danny Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823836#comment-16823836
 ] 

Danny Chan edited comment on CALCITE-2282 at 4/23/19 8:43 AM:
--

[~julianhyde] After i remove the code snippet, the unparsed sql identifier is 
changed and are all quoted, like:
{code:java}
select a, sum(b) from tbl group by a
{code}
is unparsed to:
{code:java}
select `a`, `sum`(`b`) from `tbl` group by `a`
{code}
For most of the builtin functions, this is correct, but for builtin functions 
without arguments, this semantics would change, for example, these 2 sqls are 
not equal:
{code:java}
select current_time from tbl;
select `current_time` from tbl;{code}
I think maybe we should tell users not to unparse a non-validated SqlNode, 
cause if there is a udf without any arguments, the semantics still changes, and 
we have no way to control this. Unless like the talking above, make the 
SqlOperatorTable in the parser pluggable.

 

 


was (Author: danny0405):
[~julianhyde] After i remove the code snippet, the unparsed sql identifier is 
changed and are all quoted, like:
{code:java}
select a, sum(b) from tbl group by a
{code}
is unparsed to:
{code:java}
select `a`, `sum`(`b`) from `tbl` group by `a`
{code}
For most of the builtin functions, this is correct, but for builtin functions 
without arguments, this semantics would change, for example, these 2 sqls are 
not equal:
{code:java}
select current_time from tbl;
select `current_time` from tbl;{code}
I think maybe we should tell users not to unparse a non-validated SqlNode, 
cause if there is a udf without any arguments, the semantics still changes, and 
we have no way to control this. Unless like the talking about, make the 
SqlOperatorTable in the parser pluggable.

 

 

> Allow OperatorTable to be pluggable in the parser
> -
>
> Key: CALCITE-2282
> URL: https://issues.apache.org/jira/browse/CALCITE-2282
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Sudheesh Katkam
>Priority: Major
> Attachments: CALCITE-2282.patch.txt
>
>
> SqlAbstractParserImpl [hardcodes OperatorTable to 
> SqlStdOperatorTable|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334].
>  Make this pluggable via a protected method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-2282) Allow OperatorTable to be pluggable in the parser

[Danny Chan (JIRA)]

[ 
https://issues.apache.org/jira/browse/CALCITE-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823836#comment-16823836
 ] 

Danny Chan commented on CALCITE-2282:
-

[~julianhyde] After i remove the code snippet, the unparsed sql identifier is 
changed and are all quoted, like:
{code:java}
select a, sum(b) from tbl group by a
{code}
is unparsed to:
{code:java}
select `a`, `sum`(`b`) from `tbl` group by `a`
{code}
For most of the builtin functions, this is correct, but for builtin functions 
without arguments, this semantics would change, for example, these 2 sqls are 
not equal:
{code:java}
select current_time from tbl;
select `current_time` from tbl;{code}
I think maybe we should tell users not to unparse a non-validated SqlNode, 
cause if there is a udf without any arguments, the semantics still changes, and 
we have no way to control this. Unless like the talking about, make the 
SqlOperatorTable in the parser pluggable.

 

 

> Allow OperatorTable to be pluggable in the parser
> -
>
> Key: CALCITE-2282
> URL: https://issues.apache.org/jira/browse/CALCITE-2282
> Project: Calcite
>  Issue Type: Bug
>  Components: core
>Reporter: Sudheesh Katkam
>Priority: Major
> Attachments: CALCITE-2282.patch.txt
>
>
> SqlAbstractParserImpl [hardcodes OperatorTable to 
> SqlStdOperatorTable|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334|https://github.com/apache/calcite/blob/8327e674e7f0a768d124fa37fd75cda4b8a35bb6/core/src/main/java/org/apache/calcite/sql/parser/SqlAbstractParserImpl.java#L334].
>  Make this pluggable via a protected method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)