[jira] [Updated] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
[
https://issues.apache.org/jira/browse/CALCITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6074:
Labels: pull-request-available (was: )
> The size of REAL, DOUBLE, and FLOAT is not consistent
> -
>
> Key: CALCITE-6074
> URL: https://issues.apache.org/jira/browse/CALCITE-6074
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> This stems from the review of CALCITE-6052
> Which one is 8 bytes and which one is 4 bytes?
> The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8
> bytes, (which is very weird for Java users), and REAL is 4 bytes.
> But an audit of the code shows that:
> In AggregateNode.maxMinClass:
> {code:java}
> case FLOAT:
> return max ? MaxFloat.class : MinFloat.class;
> case DOUBLE:
> case REAL:
> return max ? MaxDouble.class : MinDouble.class;
> {code}
> In VisitorDataContext:
> {code:java}
> case DOUBLE:
> return Pair.of(index, rexLiteral.getValueAs(Double.class));
> case REAL:
> return Pair.of(index, rexLiteral.getValueAs(Float.class));
> {code}
> (no case for FLOAT)
> In RelMdSize:
> {code:java}
>case FLOAT:
> case REAL:
>
> return 4d;
> {code}
> in RelDataTypeFactoryImpl:
> {code:java}
> case REAL:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case FLOAT:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case DOUBLE:
> // the default max precision is 19, so this is actually DECIMAL(19, 15)
> // but derived system can override the max precision/scale.
> return createSqlType(SqlTypeName.DECIMAL, 30, 15);
> {code}
> The reference.md itself seems to be wrong:
> {code}
> | REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
> | DOUBLE | 8 byte floating point | 15 decimal digits precision.
> {code}
> and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6078) Explicit cast to DECIMAL types do not check for overflow
[ https://issues.apache.org/jira/browse/CALCITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781154#comment-17781154 ] Mihai Budiu commented on CALCITE-6078: -- I don't think it's an exact duplicate. This issue is just about the runtime behavior of casts assuming that the types are specified. As I read the other issue, it also seems to be about the type inference: what is the inferred precision of the scale of the intermediate results? There is also [CALCITE-6073], which is more related to [CALCITE-5860] > Explicit cast to DECIMAL types do not check for overflow > > > Key: CALCITE-6078 > URL: https://issues.apache.org/jira/browse/CALCITE-6078 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > > This is a follow-up from [CALCITE-5990] > That issue dealt with integers and floating point. > This issue is about casts to DECIMAL in which the cast value exceeds the > scale of the target result. Apparently Calcite does not handle such casts > properly. There are multiple disabled SqlOperatorTests for this condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-129) Support recursive WITH queries
[
https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-129.
-
Resolution: Fixed
Fixed in
[0b12f602|https://github.com/apache/calcite/commit/0b12f6020774f7203b5ad46109020319322a8e6f];
thanks for the PR, [~hanu.ncr]!
> Support recursive WITH queries
> --
>
> Key: CALCITE-129
> URL: https://issues.apache.org/jira/browse/CALCITE-129
> Project: Calcite
> Issue Type: Improvement
>Reporter: GitHub Import
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: github-import, pull-request-available
> Fix For: 1.36.0
>
>
> Building on CALCITE-128, enable the {{RECURSIVE}} keyword.
> This feature allows relations to be computed iteratively. Whereas CALCITE-128
> was mainly a parser/validator change, this feature requires significant
> changes to the planner and runtime.
> {noformat}
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/129
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels: enhancement,
> Created at: Tue Feb 11 20:29:35 CET 2014
> State: open
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6052) SqlImplementor writes REAL, FLOAT, or DOUBLE literals as DECIMAL literals
[ https://issues.apache.org/jira/browse/CALCITE-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-6052. -- Resolution: Fixed Fixed in [782d327d|https://github.com/apache/calcite/commit/782d327d24c04e2161102b22f8880204462befd4]. > SqlImplementor writes REAL, FLOAT, or DOUBLE literals as DECIMAL literals > - > > Key: CALCITE-6052 > URL: https://issues.apache.org/jira/browse/CALCITE-6052 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > > This bug is already fixed in https://github.com/apache/calcite/pull/3411, but > I plan to submit a smaller point fix for it, which doesn't require reworking > the type families. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5858) Add REGEXP_CONTAINS, REGEXP_EXTRACT, REGEXP_EXTRACT_ALL, REGEXP_INSTR, REGEXP_REPLACE and REGEXP_SUBSTR functions (enabled in BigQuery library)
[ https://issues.apache.org/jira/browse/CALCITE-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerin John resolved CALCITE-5858. - Fix Version/s: 1.36.0 Resolution: Resolved > Add REGEXP_CONTAINS, REGEXP_EXTRACT, REGEXP_EXTRACT_ALL, REGEXP_INSTR, > REGEXP_REPLACE and REGEXP_SUBSTR functions (enabled in BigQuery library) > --- > > Key: CALCITE-5858 > URL: https://issues.apache.org/jira/browse/CALCITE-5858 > Project: Calcite > Issue Type: New Feature >Reporter: Jerin John >Assignee: Jerin John >Priority: Major > Fix For: 1.36.0 > > > Add support for REGEX_* string functions in BigQuery. > Function descriptions: > * REGEXP_CONTAINS: Returns TRUE if input value is a partial match for the > regular expression. > * REGEXP_EXTRACT: Returns the substring in input value that matches the > regular expression. Returns NULL if there is no match. > * REGEXP_EXTRACT_ALL: Returns an array of all substrings of input value that > match the regular expression. Returns an empty array if there is no match. > * REGEXP_INSTR: Returns the lowest 1-based position of a regular expression > in an input value. > * REGEXP_REPLACE: Returns a STRING where all substrings of input value that > match regular expression are replaced with the input replacement. > * REGEXP_SUBSTR: Synonym for REGEXP_EXTRACT, returns the substring in input > value that matches the regular expression. Returns NULL if there is no match. > More on these functions and their syntax may be found here: [BigQuery > Doc|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_contains] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5863) Calcite rejects valid query with multiple ORDER BY columns and constant RANGE bounds in window functions
[
https://issues.apache.org/jira/browse/CALCITE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Itiel Sadeh updated CALCITE-5863:
-
Fix Version/s: (was: 1.36.0)
> Calcite rejects valid query with multiple ORDER BY columns and constant RANGE
> bounds in window functions
>
>
> Key: CALCITE-5863
> URL: https://issues.apache.org/jira/browse/CALCITE-5863
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.34.0
>Reporter: Itiel Sadeh
>Priority: Major
> Labels: pull-request-available
>
> Usually, it is not valid to specify multiple ORDER BY columns with RANGE
> bounds in window functions:
> {code:java}
> SELECT sum(x) OVER (ORDER BY x,y RANGE BETWEEN 3 preceding and 4 following)
> from t;{code}
> However, it is valid if both bounds are "constant" bound (CURRENT ROW,
> UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING), i.e:
> {code:java}
> SELECT sum(x) OVER (ORDER BY x,y RANGE BETWEEN UNBOUNDED PRECEDING and
> CURRENT ROW) from t;{code}
> (tested on PostgreSQL and SQL Server)
> Calcite will incorrectly reject it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5863) Calcite rejects valid query with multiple ORDER BY columns and constant RANGE bounds in window functions
[
https://issues.apache.org/jira/browse/CALCITE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Itiel Sadeh updated CALCITE-5863:
-
Fix Version/s: 1.36.0
> Calcite rejects valid query with multiple ORDER BY columns and constant RANGE
> bounds in window functions
>
>
> Key: CALCITE-5863
> URL: https://issues.apache.org/jira/browse/CALCITE-5863
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.34.0
>Reporter: Itiel Sadeh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Usually, it is not valid to specify multiple ORDER BY columns with RANGE
> bounds in window functions:
> {code:java}
> SELECT sum(x) OVER (ORDER BY x,y RANGE BETWEEN 3 preceding and 4 following)
> from t;{code}
> However, it is valid if both bounds are "constant" bound (CURRENT ROW,
> UNBOUNDED PRECEDING and UNBOUNDED FOLLOWING), i.e:
> {code:java}
> SELECT sum(x) OVER (ORDER BY x,y RANGE BETWEEN UNBOUNDED PRECEDING and
> CURRENT ROW) from t;{code}
> (tested on PostgreSQL and SQL Server)
> Calcite will incorrectly reject it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-129) Support recursive WITH queries
[
https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781029#comment-17781029
]
Hanumath Rao Maduri commented on CALCITE-129:
-
[~julianhyde] Thanks for the review and making the change. Please go ahead
with the merge.
> Support recursive WITH queries
> --
>
> Key: CALCITE-129
> URL: https://issues.apache.org/jira/browse/CALCITE-129
> Project: Calcite
> Issue Type: Improvement
>Reporter: GitHub Import
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: github-import, pull-request-available
> Fix For: 1.36.0
>
>
> Building on CALCITE-128, enable the {{RECURSIVE}} keyword.
> This feature allows relations to be computed iteratively. Whereas CALCITE-128
> was mainly a parser/validator change, this feature requires significant
> changes to the planner and runtime.
> {noformat}
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/129
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels: enhancement,
> Created at: Tue Feb 11 20:29:35 CET 2014
> State: open
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao resolved CALCITE-6041.
--
Resolution: Resolved
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> 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:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781005#comment-17781005
]
Ran Tao edited comment on CALCITE-6041 at 10/30/23 1:30 PM:
Fixed via
[c5f3b8d|https://github.com/apache/calcite/commit/c5f3b8dcf14bd66d435a7fd3b6150ea1b3d3ccd7]
thanks Julian for reviewing!
was (Author: lemonjing):
Fixed via
[c5f3b8d|https://github.com/apache/calcite/commit/c5f3b8dcf14bd66d435a7fd3b6150ea1b3d3ccd7]
thanks Julian for reviewing.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> 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:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
>
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781005#comment-17781005
]
Ran Tao commented on CALCITE-6041:
--
Fixed via
[c5f3b8d|https://github.com/apache/calcite/commit/c5f3b8dcf14bd66d435a7fd3b6150ea1b3d3ccd7]
thanks Julian for reviewing.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> 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:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
>
[jira] [Commented] (CALCITE-6078) Explicit cast to DECIMAL types do not check for overflow
[ https://issues.apache.org/jira/browse/CALCITE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780983#comment-17780983 ] Stamatis Zampetakis commented on CALCITE-6078: -- [~mbudiu] Is this a duplicate of CALCITE-5860? > Explicit cast to DECIMAL types do not check for overflow > > > Key: CALCITE-6078 > URL: https://issues.apache.org/jira/browse/CALCITE-6078 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Priority: Minor > > This is a follow-up from [CALCITE-5990] > That issue dealt with integers and floating point. > This issue is about casts to DECIMAL in which the cast value exceeds the > scale of the target result. Apparently Calcite does not handle such casts > properly. There are multiple disabled SqlOperatorTests for this condition. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6077) Add FACTORIAL function (enabled in Hive and Spark libraries)
[
https://issues.apache.org/jira/browse/CALCITE-6077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-6077.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[7eace909|https://github.com/apache/calcite/commit/7eace909c51a3f56953597264d9c577c4e088852];
thanks for the PR, [~Runking]!
> Add FACTORIAL function (enabled in Hive and Spark libraries)
>
>
> Key: CALCITE-6077
> URL: https://issues.apache.org/jira/browse/CALCITE-6077
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add FACTORIAL function (enabled in Hive and Spark libraries)
> FACTORIAL(expr): Returns the factorial of expr. expr is [0..20]. Otherwise,
> returns NULL.
> For example:
> {code:sql}
> SELECT factorial(5);
> >120
> {code}
> See more at
> [Hive|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf#LanguageManualUDF-MathematicalFunctions]
> and
> [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#factorial] doc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5979) Add REGEXP_REPLACE function (enabled in BigQuery library)
[
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-5979.
--
Fix Version/s: 1.36.0
Resolution: Fixed
Fixed in
[c6b3876f|https://github.com/apache/calcite/commit/c6b3876ff4707527ca3c952036312a11bbc4ca4f];
thanks for the PR, [~jerin_john]!
> Add REGEXP_REPLACE function (enabled in BigQuery library)
> -
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
> Issue Type: Task
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Add support for [REGEXP_REPLACE
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
> function from BigQuery.
> *{{REGEXP_REPLACE(value, regexp, replacement)}}*
> Returns a STRING where all substrings of {{value}} that match regular
> expression {{regexp}} are replaced with {{{}replacement{}}}.
> backslashed-escaped digits (\1 to \9) can be used within the {{replacement}}
> argument to insert text matching the corresponding parenthesized group in the
> {{regexp}} pattern.
> Example (added one space between \ \ to override md formatting):
> {{SELECT REGEXP_REPLACE("abc'", "b(.)", "X\ \1") as result;}}
> |result|
> |aXc|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-129) Support recursive WITH queries
[
https://issues.apache.org/jira/browse/CALCITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780860#comment-17780860
]
Julian Hyde commented on CALCITE-129:
-
[~hanu.ncr], Thanks for addressing the various issues that people have noted in
the PR. It's almost ready, but for one thing. I have changed
{{WithItemRecursiveNamespace}} so that it overrides {{validateImpl}} rather
than {{getRowType}}. Please take a look at the commit I added in
[129-with-recursive|https://github.com/julianhyde/calcite/tree/129-with-recursive].
If it looks OK I'll squash and merge.
> Support recursive WITH queries
> --
>
> Key: CALCITE-129
> URL: https://issues.apache.org/jira/browse/CALCITE-129
> Project: Calcite
> Issue Type: Improvement
>Reporter: GitHub Import
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: github-import, pull-request-available
> Fix For: 1.36.0
>
>
> Building on CALCITE-128, enable the {{RECURSIVE}} keyword.
> This feature allows relations to be computed iteratively. Whereas CALCITE-128
> was mainly a parser/validator change, this feature requires significant
> changes to the planner and runtime.
> {noformat}
> Imported from GitHub
> Url: https://github.com/julianhyde/optiq/issues/129
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels: enhancement,
> Created at: Tue Feb 11 20:29:35 CET 2014
> State: open
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
