[jira] [Updated] (CALCITE-3704) Implement STRCMP function
[ https://issues.apache.org/jira/browse/CALCITE-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3704: Labels: pull-request-available (was: ) > Implement STRCMP function > - > > Key: CALCITE-3704 > URL: https://issues.apache.org/jira/browse/CALCITE-3704 > Project: Calcite > Issue Type: Improvement >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > > IMPLEMENT STRCMP FUNCTION > MySQL strcmp() function is used to compare two strings. It returns 0 if both > of the strings are same and returns -1 when the first argument is smaller > than the second according to the defined order and 1 when the second one is > smaller the first one. > *Syntax:* > STRCMP (expr1, expr2) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved CALCITE-2704.
-
Resolution: Fixed
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Blocker
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated CALCITE-2704:
Priority: Major (was: Blocker)
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-2704) Multilingual decoded problem
[
https://issues.apache.org/jira/browse/CALCITE-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reassigned CALCITE-2704:
---
Assignee: Feng Zhu
> Multilingual decoded problem
>
>
> Key: CALCITE-2704
> URL: https://issues.apache.org/jira/browse/CALCITE-2704
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: avatica-1.11.0, avatica-1.12.0, avatica-1.13.0
>Reporter: pufan
>Assignee: Feng Zhu
>Priority: Blocker
> Labels: pull-request-available
> Fix For: avatica-1.17.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> When we execute SQL with Chinese characters, we find that the server parses
> it in gibberish.
> After checking the code, we found that:
> org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 109：
> {code:java}
> //The readFully method USES utf-8 encoding internally.
> rawRequest = AvaticaUtils.readFully(inputStream, buffer);
> {code}
> But in the org.apache.calcite.avatica.server.AvaticaJsonHandler.java line 116：
> {code:java}
> // Decoded using iso-8859-1 Cause Chinese garble.
> final String jsonRequest = new String(rawRequest.getBytes("ISO-8859-1"),
> "UTF-8");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3745) UnitCompiler can not find required class information.
[
https://issues.apache.org/jira/browse/CALCITE-3745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3745:
Labels: pull-request-available (was: )
> UnitCompiler can not find required class information.
> -
>
> Key: CALCITE-3745
> URL: https://issues.apache.org/jira/browse/CALCITE-3745
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
> Environment:
> stacktrace:
> {code:java}
> Caused by: org.codehaus.commons.compiler.CompileException: Line 687, Column
> 40: Cannot determine simple type name "com"Caused by:
> org.codehaus.commons.compiler.CompileException: Line 687, Column 40: Cannot
> determine simple type name "com" at
> org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12124) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6746) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6507) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
> org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6486) at
> org.codehaus.janino.UnitCompiler.access$13800(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$21$1.visitReferenceType(UnitCompiler.java:6394)
> at
> org.codehaus.janino.UnitCompiler$21$1.visitReferenceType(UnitCompiler.java:6389)
> at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3917) at
> org.codehaus.janino.UnitCompiler$21.visitType(UnitCompiler.java:6389) at
> org.codehaus.janino.UnitCompiler$21.visitType(UnitCompiler.java:6382) at
> org.codehaus.janino.Java$ReferenceType.accept(Java.java:3916) at
> org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6382) at
> org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:7034) at
> org.codehaus.janino.UnitCompiler.access$16900(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$21$2.visitNewClassInstance(UnitCompiler.java:6442)
> at
> org.codehaus.janino.UnitCompiler$21$2.visitNewClassInstance(UnitCompiler.java:6403)
> at org.codehaus.janino.Java$NewClassInstance.accept(Java.java:5179) at
> org.codehaus.janino.UnitCompiler$21.visitRvalue(UnitCompiler.java:6403) at
> org.codehaus.janino.UnitCompiler$21.visitRvalue(UnitCompiler.java:6382) at
> org.codehaus.janino.Java$Rvalue.accept(Java.java:4105) at
> org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6382) at
> org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8939) at
> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5060) at
> org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4421)
> at
> org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4394)
> at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:5062) at
> org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4394) at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5575) at
> org.codehaus.janino.UnitCompiler.compileBoolean2(UnitCompiler.java:4147) at
> org.codehaus.janino.UnitCompiler.access$6600(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$14.visitBinaryOperation(UnitCompiler.java:3955)
> at
> org.codehaus.janino.UnitCompiler$14.visitBinaryOperation(UnitCompiler.java:3933)
> at org.codehaus.janino.Java$BinaryOperation.accept(Java.java:4853) at
> org.codehaus.janino.UnitCompiler.compileBoolean(UnitCompiler.java:3933) at
> org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4709) at
> org.codehaus.janino.UnitCompiler.access$8800(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$16.visitConditionalExpression(UnitCompiler.java:4418)
> at
> org.codehaus.janino.UnitCompiler$16.visitConditionalExpression(UnitCompiler.java:4394)
> at org.codehaus.janino.Java$ConditionalExpression.accept(Java.java:4504) at
> org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4394) at
> org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5575) at
> org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:2580) at
> org.codehaus.janino.UnitCompiler.access$2700(UnitCompiler.java:215) at
> org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler.java:1503)
> at
> org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler
[jira] [Commented] (CALCITE-3746) RexSimplify changes the order of IS NOT NULL in And RexNode
[
https://issues.apache.org/jira/browse/CALCITE-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017924#comment-17017924
]
Vladimir Sitnikov commented on CALCITE-3746:
{quote}length(a) > 0 and a is not null
which will affect the logic short circuit for null-test.{quote}
Please clarify how it will affect the logic.
> RexSimplify changes the order of IS NOT NULL in And RexNode
> ---
>
> Key: CALCITE-3746
> URL: https://issues.apache.org/jira/browse/CALCITE-3746
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The RexSimplify changes the order of IS NOT NULL in And RexNode.The following
> expression
> {code:java}
> a is not null and length(a) > 0{code}
> is optimazted to
> {code:java}
> length(a) > 0 and a is not null{code}
> which will affect the logic short circuit for null-test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3746) RexSimplify changes the order of IS NOT NULL in And RexNode
[
https://issues.apache.org/jira/browse/CALCITE-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017916#comment-17017916
]
Vladimir Sitnikov commented on CALCITE-3746:
The issue is invalid.
The order of AND operands must not be significant.
> RexSimplify changes the order of IS NOT NULL in And RexNode
> ---
>
> Key: CALCITE-3746
> URL: https://issues.apache.org/jira/browse/CALCITE-3746
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The RexSimplify changes the order of IS NOT NULL in And RexNode.The following
> expression
> {code:java}
> a is not null and length(a) > 0{code}
> is optimazted to
> {code:java}
> length(a) > 0 and a is not null{code}
> which will affect the logic short circuit for null-test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3746) RexSimplify changes the order of IS NOT NULL in And RexNode
[
https://issues.apache.org/jira/browse/CALCITE-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3746:
Labels: pull-request-available (was: )
> RexSimplify changes the order of IS NOT NULL in And RexNode
> ---
>
> Key: CALCITE-3746
> URL: https://issues.apache.org/jira/browse/CALCITE-3746
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
>
> The RexSimplify changes the order of IS NOT NULL in And RexNode.The following
> expression
> {code:java}
> a is not null and length(a) > 0{code}
> is optimazted to
> {code:java}
> length(a) > 0 and a is not null{code}
> which will affect the logic short circuit for null-test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3746) RexSimplify changes the order of IS NOT NULL in And RexNode
pengzhiwei created CALCITE-3746:
---
Summary: RexSimplify changes the order of IS NOT NULL in And
RexNode
Key: CALCITE-3746
URL: https://issues.apache.org/jira/browse/CALCITE-3746
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.20.0
Reporter: pengzhiwei
Assignee: pengzhiwei
The RexSimplify changes the order of IS NOT NULL in And RexNode.The following
expression
{code:java}
a is not null and length(a) > 0{code}
is optimazted to
{code:java}
length(a) > 0 and a is not null{code}
which will affect the logic short circuit for null-test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3732) Implement bit functions and operators
[ https://issues.apache.org/jira/browse/CALCITE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017856#comment-17017856 ] hailong wang commented on CALCITE-3732: --- [~julianhyde] Maybe we can call BITAND, BITOR etc. like snowflake and DB2 which are no underscore compared with aggregate functions ? > Implement bit functions and operators > - > > Key: CALCITE-3732 > URL: https://issues.apache.org/jira/browse/CALCITE-3732 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Fix For: 1.22.0 > > > Bit function is non-standard operators, but all db has implemented, such as > mysql, postgresql. > Calcite has implemented BIT_AND, BIT_OR in > https://issues.apache.org/jira/browse/CALCITE-2770, BIT_XOR in > https://issues.apache.org/jira/browse/CALCITE-3591. BIT_COUNT is in progress > https://issues.apache.org/jira/browse/CALCITE-3697, BIT_NOT(~) is in progress > https://issues.apache.org/jira/browse/CALCITE-3592. > So I think we should also implement Bitwise AND(&), Right shift(>>), Left > shift(<<), Bitwise XOR(^), Bitwise OR(|). And data types support tinyint, > smallint, int, bigint like before. > > Refence: > [https://dev.mysql.com/doc/refman/8.0/en/bit-functions.html#operator_bitwise-invert] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3745) UnitCompiler can not find required class information.
SHEN KAI created CALCITE-3745:
-
Summary: UnitCompiler can not find required class information.
Key: CALCITE-3745
URL: https://issues.apache.org/jira/browse/CALCITE-3745
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Environment:
stacktrace:
{code:java}
Caused by: org.codehaus.commons.compiler.CompileException: Line 687, Column 40:
Cannot determine simple type name "com"Caused by:
org.codehaus.commons.compiler.CompileException: Line 687, Column 40: Cannot
determine simple type name "com" at
org.codehaus.janino.UnitCompiler.compileError(UnitCompiler.java:12124) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6746) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6507) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getReferenceType(UnitCompiler.java:6520) at
org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:6486) at
org.codehaus.janino.UnitCompiler.access$13800(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$21$1.visitReferenceType(UnitCompiler.java:6394)
at
org.codehaus.janino.UnitCompiler$21$1.visitReferenceType(UnitCompiler.java:6389)
at org.codehaus.janino.Java$ReferenceType.accept(Java.java:3917) at
org.codehaus.janino.UnitCompiler$21.visitType(UnitCompiler.java:6389) at
org.codehaus.janino.UnitCompiler$21.visitType(UnitCompiler.java:6382) at
org.codehaus.janino.Java$ReferenceType.accept(Java.java:3916) at
org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6382) at
org.codehaus.janino.UnitCompiler.getType2(UnitCompiler.java:7034) at
org.codehaus.janino.UnitCompiler.access$16900(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$21$2.visitNewClassInstance(UnitCompiler.java:6442)
at
org.codehaus.janino.UnitCompiler$21$2.visitNewClassInstance(UnitCompiler.java:6403)
at org.codehaus.janino.Java$NewClassInstance.accept(Java.java:5179) at
org.codehaus.janino.UnitCompiler$21.visitRvalue(UnitCompiler.java:6403) at
org.codehaus.janino.UnitCompiler$21.visitRvalue(UnitCompiler.java:6382) at
org.codehaus.janino.Java$Rvalue.accept(Java.java:4105) at
org.codehaus.janino.UnitCompiler.getType(UnitCompiler.java:6382) at
org.codehaus.janino.UnitCompiler.findIMethod(UnitCompiler.java:8939) at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:5060) at
org.codehaus.janino.UnitCompiler.access$9100(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4421)
at
org.codehaus.janino.UnitCompiler$16.visitMethodInvocation(UnitCompiler.java:4394)
at org.codehaus.janino.Java$MethodInvocation.accept(Java.java:5062) at
org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4394) at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5575) at
org.codehaus.janino.UnitCompiler.compileBoolean2(UnitCompiler.java:4147) at
org.codehaus.janino.UnitCompiler.access$6600(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$14.visitBinaryOperation(UnitCompiler.java:3955)
at
org.codehaus.janino.UnitCompiler$14.visitBinaryOperation(UnitCompiler.java:3933)
at org.codehaus.janino.Java$BinaryOperation.accept(Java.java:4853) at
org.codehaus.janino.UnitCompiler.compileBoolean(UnitCompiler.java:3933) at
org.codehaus.janino.UnitCompiler.compileGet2(UnitCompiler.java:4709) at
org.codehaus.janino.UnitCompiler.access$8800(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$16.visitConditionalExpression(UnitCompiler.java:4418)
at
org.codehaus.janino.UnitCompiler$16.visitConditionalExpression(UnitCompiler.java:4394)
at org.codehaus.janino.Java$ConditionalExpression.accept(Java.java:4504) at
org.codehaus.janino.UnitCompiler.compileGet(UnitCompiler.java:4394) at
org.codehaus.janino.UnitCompiler.compileGetValue(UnitCompiler.java:5575) at
org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:2580) at
org.codehaus.janino.UnitCompiler.access$2700(UnitCompiler.java:215) at
org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler.java:1503)
at
org.codehaus.janino.UnitCompiler$6.visitLocalVariableDeclarationStatement(UnitCompiler.java:1487)
at
org.codehaus.janino.Java$LocalVariableDeclarationStatement.accept(Java.java:3511)
at org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:1487) at
org.codehaus.janino.UnitCompiler.compileStatements(UnitCompiler.java:1567) at
org.codehaus.janino.UnitCompiler.compile(UnitCompiler.java:3388) at
org.codehaus.janino.UnitCompiler.com
