[jira] [Updated] (CALCITE-6411) Support Collect in ToLogicalConverter
[ https://issues.apache.org/jira/browse/CALCITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6411: Labels: pull-request-available (was: ) > Support Collect in ToLogicalConverter > - > > Key: CALCITE-6411 > URL: https://issues.apache.org/jira/browse/CALCITE-6411 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > Support Collect operator expression convert to Logical in ToLogicalConverter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6369) Expanding "star" gives ArrayIndexOutOfBoundsException with redundant columns and USING
[
https://issues.apache.org/jira/browse/CALCITE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6369:
Labels: pull-request-available (was: )
> Expanding "star" gives ArrayIndexOutOfBoundsException with redundant columns
> and USING
> --
>
> Key: CALCITE-6369
> URL: https://issues.apache.org/jira/browse/CALCITE-6369
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> The query
> {code}
> select r_regionkey, * from region r0 join region r1 using (r_regionkey)
> {code}
> produces
> {code}
> java.lang.ArrayIndexOutOfBoundsException: Index 14 out of bounds for length 14
> at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
> (PairLists.java:573)
> at org.apache.calcite.runtime.PairLists$ArrayImmutablePairList.get
> (PairLists.java:550)
> at org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute
> (SqlValidatorImpl.java:7443)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar
> (SqlValidatorImpl.java:697)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem
> (SqlValidatorImpl.java:453)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList
> (SqlValidatorImpl.java:4658)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
> (SqlValidatorImpl.java:3840)
> at org.apache.calcite.sql.validate.SelectNamespace.validateImpl
> (SelectNamespace.java:61)
> at org.apache.calcite.sql.validate.AbstractNamespace.validate
> (AbstractNamespace.java:88)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace
> (SqlValidatorImpl.java:1154)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery
> (SqlValidatorImpl.java:1125)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6310) Add REGEXP_REPLACE function (enabled in PostgreSQL library)
[ https://issues.apache.org/jira/browse/CALCITE-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6310: Labels: pull-request-available (was: ) > Add REGEXP_REPLACE function (enabled in PostgreSQL library) > --- > > Key: CALCITE-6310 > URL: https://issues.apache.org/jira/browse/CALCITE-6310 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: James Duong >Priority: Minor > Labels: pull-request-available > > * There is an existing implementation. > * PostgreSQL requires supporting an optional extra flags argument -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6422) RexLiteral.isNullLiteral should be applied before RexLiteral.booleanValue in SubstitutionVisitor.mayBeSatisfiable
[
https://issues.apache.org/jira/browse/CALCITE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6422:
Labels: pull-request-available (was: )
> RexLiteral.isNullLiteral should be applied before RexLiteral.booleanValue in
> SubstitutionVisitor.mayBeSatisfiable
> -
>
> Key: CALCITE-6422
> URL: https://issues.apache.org/jira/browse/CALCITE-6422
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
> Labels: pull-request-available
>
> Add the test case in MaterializedViewRelOptRulesTest to reproduce this bug:
> {code:java}
> @Test public void testNpeInSplitFilterOfSubstitutionVisitor() {
> sql("select \"col1\", \"col2\""
> + " from \"nullables\""
> + " where \"col1\" <> \"col2\" and \"col3\" = 1",
> "select \"col1\", \"col2\""
> + " from \"nullables\""
> + " where \"col1\" = \"col2\" and \"col3\" = 1")
> .checkingThatResultContains(""
> + "EnumerableCalc(expr#0..2=[{inputs}], expr#3=[=($t0, $t1)],
> expr#4=[CAST($t2):INTEGER NOT NULL], expr#5=[1], expr#6=[=($t4, $t5)],
> expr#7=[AND($t3, $t6)], proj#0..1=[{exprs}], $condition=[$t7])\n"
> + " EnumerableTableScan(table=[[hr, nullables]])")
> .ok();
> } {code}
> A NPE will be thrown.
> Notes: col1 and col2 of table nullables should be nullable.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6419) Invalid unparse for VARCHAR without precision in HiveSqlDialect And SparkSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6419:
Labels: pull-request-available (was: )
> Invalid unparse for VARCHAR without precision in HiveSqlDialect And
> SparkSqlDialect
> ---
>
> Key: CALCITE-6419
> URL: https://issues.apache.org/jira/browse/CALCITE-6419
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When we execute SQL in Calcite:
> {code:java}
> select cast(product_id as varchar) from product;
> {code}
> Generage the HiveSQL\SparkSQL:
> {code:java}
> select cast(product_id as varchar) from product;
> {code}
> According to the
> [https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types#LanguageManualTypes-VarcharvarcharVarchar].
> In Hive, the varchar must have a precision.So when unpare VARCHAR without
> precision, I will convert VARCHAR to String. VARCHAR with precison do nothing.
> According to the
> [https://spark.apache.org/docs/latest/sql-ref-datatypes.html].
> In Spark, Same as Hive. But as note, It can only be used in table schema, not
> functions/operators. So I will convert VARCHAR with or without precision to
> String;
> In SparkSQL, Varchar with precision are not effective, but no error and just
> a warning:
> {code:java}
> spark-sql> select cast('value' as varchar(2));
> 24/05/24 16:04:39 WARN CharVarcharUtils: The Spark cast operator does not
> support char/varchar type and simply treats them as string type. Please use
> string type directly to avoid confusion. Otherwise, you can set
> spark.sql.legacy.charVarcharAsString to true, so that Spark treat them as
> string type as same as Spark 3.0 and earlier
> value
> Time taken: 2.797 seconds, Fetched 1 row(s){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6421) Calcite Avatica support JDK 22
[ https://issues.apache.org/jira/browse/CALCITE-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6421: Labels: pull-request-available (was: ) > Calcite Avatica support JDK 22 > -- > > Key: CALCITE-6421 > URL: https://issues.apache.org/jira/browse/CALCITE-6421 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Sergey Nuyanzin >Assignee: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6417) Map value constructor and Array value constructor unparsed incorrectly for HiveSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6417:
Labels: pull-request-available (was: )
> Map value constructor and Array value constructor unparsed incorrectly for
> HiveSqlDialect
> -
>
> Key: CALCITE-6417
> URL: https://issues.apache.org/jira/browse/CALCITE-6417
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The SQL：
> {code:java}
> SELECT MAP['k1', 'v1', 'k2', 'v2'],ARRAY[1, 2, 3]{code}
> Generate Hive SQL should be：
> {code:java}
> SELECT MAP ('k1', 'v1', 'k2', 'v2'),ARRAY (1, 2, 3){code}
> But is:
> {code:java}
> SELECT MAP['k1', 'v1', 'k2', 'v2'],ARRAY[1, 2, 3]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6370) AS operator problems with USING clause
[
https://issues.apache.org/jira/browse/CALCITE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6370:
Labels: pull-request-available (was: )
> AS operator problems with USING clause
> --
>
> Key: CALCITE-6370
> URL: https://issues.apache.org/jira/browse/CALCITE-6370
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> In some cases, with the {{USING}} clause, the used column generates ambiguity
> exceptions with the {{AS}} operator.
>
> OK : {{select r_regionkey from region r0 join region r1 using (r_regionkey)}}
> OK : {{select r_regionkey * 2 as rk2 from region r0 join region r1 using
> (r_regionkey)}}
> KO : {{select r_regionkey as rk from region r0 join region r1 using
> (r_regionkey)}}
>
> The last query generates the following error:
>
> {code:java}
> org.apache.calcite.sql.validate.SqlValidatorException: Column 'r_regionkey'
> is ambiguous
> at jdk.internal.reflect.DirectConstructorHandleAccessor.newInstance
> (DirectConstructorHandleAccessor.java:62)
> at java.lang.reflect.Constructor.newInstanceWithCaller
> (Constructor.java:502)
> at java.lang.reflect.Constructor.newInstance (Constructor.java:486)
> at org.apache.calcite.runtime.Resources$ExInstWithCause.ex
> (Resources.java:507)
> at org.apache.calcite.runtime.Resources$ExInst.ex (Resources.java:601)
> at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:948)
> at org.apache.calcite.sql.SqlUtil.newContextException (SqlUtil.java:933)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError
> (SqlValidatorImpl.java:5517)
> at org.apache.calcite.sql.validate.DelegatingScope.fullyQualify
> (DelegatingScope.java:296)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.findTableColumnPair
> (SqlValidatorImpl.java:3989)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.isRolledUpColumn
> (SqlValidatorImpl.java:4032)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3945)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3940)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUp
> (SqlValidatorImpl.java:3959)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkRollUpInSelectList
> (SqlValidatorImpl.java:3861)
> at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect
> (SqlValidatorImpl.java:3849)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6416) Remove unnecessary SUBSTRING rewrite in SparkSqlDialect
[ https://issues.apache.org/jira/browse/CALCITE-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6416: Labels: pull-request-available (was: ) > Remove unnecessary SUBSTRING rewrite in SparkSqlDialect > --- > > Key: CALCITE-6416 > URL: https://issues.apache.org/jira/browse/CALCITE-6416 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.37.0 >Reporter: xiong duan >Assignee: xiong duan >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > SparkSqlDialect have a unnecessary rewrite about SUBSTRING func. > In CALCITE-3247, We handle the SUBSTRING rewrite in HiveSqlDialect. > In CALCITE-3072, We handle the SUBSTRING rewrite in SparkSqlDialect. > In CALCITE-5677, We refactor the SUBSTRING as the default behaviour and > remove the SUBSTRING rewrite in HiveSqlDialect. This PR will remove the Spark. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6415) Invalid unparse for TIMESTAMP with HiveSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6415:
Labels: pull-request-available (was: )
> Invalid unparse for TIMESTAMP with HiveSqlDialect
> -
>
> Key: CALCITE-6415
> URL: https://issues.apache.org/jira/browse/CALCITE-6415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When parsing
> {code:java}
> SELECT CAST("2023-11-10" AS TIMESTAMP) {code}
> The unparsed Hive SQL query gives:
> {code:java}
> SELECT CAST("2023-11-10" AS TIMESTAMP(0)) {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6311) Support PostgreSQL DATE_PART
[
https://issues.apache.org/jira/browse/CALCITE-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6311:
Labels: pull-request-available (was: )
> Support PostgreSQL DATE_PART
>
>
> Key: CALCITE-6311
> URL: https://issues.apache.org/jira/browse/CALCITE-6311
> Project: Calcite
> Issue Type: Sub-task
>Reporter: James Duong
>Assignee: Norman Jordan
>Priority: Minor
> Labels: pull-request-available
>
> * PostgreSQL and Redshift let the date_part parameter be a string instead of
> a just an enum-like identifier (eg DATE_PART('year', ...) and DATE_PART(year,
> ...) are both supported.
> * SQL Server does not support using a string here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5737) Support JDK 20
[ https://issues.apache.org/jira/browse/CALCITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5737: Labels: pull-request-available (was: ) > Support JDK 20 > -- > > Key: CALCITE-5737 > URL: https://issues.apache.org/jira/browse/CALCITE-5737 > Project: Calcite > Issue Type: Sub-task >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > > Support JDK 20. > We currently support JDK (and OpenJDK) versions up to 18. (CALCITE-5747 will > add support for JDK 19.) JDK 20 is the latest. We should support JDK 20 in > Calcite 1.35 if possible, or soon after. > This change would modify history.md (for the upcoming release), add JDK 20 to > the GitHub CI, and fix the build. There are deprecation warnings (which we > treat as errors) regarding the java.net.URL constructor. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6392) Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp
[ https://issues.apache.org/jira/browse/CALCITE-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6392: Labels: pull-request-available (was: ) > Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp > - > > Key: CALCITE-6392 > URL: https://issues.apache.org/jira/browse/CALCITE-6392 > Project: Calcite > Issue Type: Sub-task >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > Many of the date/time format patterns supported by PostgreSQL 14 are not > supported in Calcite. > * HH > * US > * > * S > * AM > * A.M. > * am > * a.m. > * PM > * P.M. > * pm > * p.m. > * Y,YYY > * YYY > * Y > * IYYY > * IYY > * IY > * I > * BC > * B.C. > * bc > * b.c. > * AD > * A.D. > * ad > * a.d. > * MONTH > * month > * MON > * mon > * DAY > * day > * Dy > * dy > * IDDD > * ID > * TZH > * TZM > * OF > There are also template pattern modifiers that need to be supported. > * FM (prefix) > * TH (suffix) > * th (suffix) > * FX (prefix) > * TM (prefix) > Some format patterns in Calcite behave differently from PostgreSQL 14. > * FF1 > * FF2 > * FF4 > * FF5 > * FF6 > Also verify that the other existing format strings produce results that match > PostgreSQL 14. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6380) Casts from INTERVAL and STRING to DECIMAL are incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6380: Labels: pull-request-available (was: ) > Casts from INTERVAL and STRING to DECIMAL are incorrect > --- > > Key: CALCITE-6380 > URL: https://issues.apache.org/jira/browse/CALCITE-6380 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > This is a follow-up from [CALCITE-6322], which is about casts from numeric > types to DECIMAL values. There are two tests in SqlOperatorTest which are > disabled due to this bug: > - testCastStringToDecimal > - testCastIntervalToNumeric -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6400) MAP_ENTRIES is not allowed to be empty
[
https://issues.apache.org/jira/browse/CALCITE-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6400:
Labels: pull-request-available (was: )
> MAP_ENTRIES is not allowed to be empty
> --
>
> Key: CALCITE-6400
> URL: https://issues.apache.org/jira/browse/CALCITE-6400
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {code:java}
> scala> val df = spark.sql("select map_entries(map('foo', 1, null, 2.0))")
> df: org.apache.spark.sql.DataFrame = [map_entries(map(foo, 1, NULL, 2.0)):
> array>]
> scala> df.show()
> org.apache.spark.SparkRuntimeException: [NULL_MAP_KEY] Cannot use null as map
> key.
> at
> org.apache.spark.sql.errors.QueryExecutionErrors$.nullAsMapKeyNotAllowedError(QueryExecutionErrors.scala:445)
> at
> org.apache.spark.sql.catalyst.util.ArrayBasedMapBuilder.put(ArrayBasedMapBuilder.scala:56)
> at
> org.apache.spark.sql.catalyst.expressions.CreateMap.eval(complexTypeCreator.scala:248)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.eval(Expression.scala:542)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.eval(Expression.scala:542)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.org$apache$spark$sql$catalyst$optimizer$ConstantFolding$$constantFolding(expressions.scala:80)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.$anonfun$constantFolding$4(expressions.scala:90)
> at
> org.apache.spark.sql.catalyst.trees.UnaryLike.mapChildren(TreeNode.scala:1249)
> at
> org.apache.spark.sql.catalyst.trees.UnaryLike.mapChildren$(TreeNode.scala:1248)
> at
> org.apache.spark.sql.catalyst.expressions.UnaryExpression.mapChildren(Expression.scala:532)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.org$apache$spark$sql$catalyst$optimizer$ConstantFolding$$constantFolding(expressions.scala:90)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.$anonfun$applyOrElse$1(expressions.scala:94)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$1(QueryPlan.scala:207)
> at
> org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:104)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.transformExpression$1(QueryPlan.scala:207)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.recursiveTransform$1(QueryPlan.scala:218)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$3(QueryPlan.scala:223)
> at
> scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286)
> at scala.collection.immutable.List.foreach(List.scala:431)
> at scala.collection.TraversableLike.map(TraversableLike.scala:286)
> at scala.collection.TraversableLike.map$(TraversableLike.scala:279)
> at scala.collection.immutable.List.map(List.scala:305)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.recursiveTransform$1(QueryPlan.scala:223)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.$anonfun$mapExpressions$4(QueryPlan.scala:228)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.mapProductIterator(TreeNode.scala:355)
> at
> org.apache.spark.sql.catalyst.plans.QueryPlan.mapExpressions(QueryPlan.scala:228)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.applyOrElse(expressions.scala:94)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$$anonfun$apply$1.applyOrElse(expressions.scala:93)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.$anonfun$transformDownWithPruning$1(TreeNode.scala:512)
> at
> org.apache.spark.sql.catalyst.trees.CurrentOrigin$.withOrigin(TreeNode.scala:104)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.transformDownWithPruning(TreeNode.scala:512)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.org$apache$spark$sql$catalyst$plans$logical$AnalysisHelper$$super$transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning(AnalysisHelper.scala:267)
> at
> org.apache.spark.sql.catalyst.plans.logical.AnalysisHelper.transformDownWithPruning$(AnalysisHelper.scala:263)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.plans.logical.LogicalPlan.transformDownWithPruning(LogicalPlan.scala:31)
> at
> org.apache.spark.sql.catalyst.trees.TreeNode.transformWithPruning(TreeNode.scala:478)
> at
> org.apache.spark.sql.catalyst.optimizer.ConstantFolding$.apply(expressions.scala:93)
> at
>
[jira] [Updated] (CALCITE-6352) The map_contains_key function may return true when the key and mapkeytype types are different.
[
https://issues.apache.org/jira/browse/CALCITE-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6352:
Labels: pull-request-available (was: )
> The map_contains_key function may return true when the key and mapkeytype
> types are different.
> --
>
> Key: CALCITE-6352
> URL: https://issues.apache.org/jira/browse/CALCITE-6352
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Critical
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
>
> {code:java}
> scala> val df = spark.sql("select map_contains_key(map(1, 'a', 2, 'b'),
> 2.0)")
> val df: org.apache.spark.sql.DataFrame = [map_contains_key(map(1, a, 2, b),
> 2.0): boolean]
> scala> df.show()
> +--+
> |map_contains_key(map(1, a, 2, b), 2.0)|
> +--+
> | true|
> +--+
> {code}
> calcite return false
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6397) Add NVL2 function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6397: Labels: pull-request-available (was: ) > Add NVL2 function (enabled in Spark library) > > > Key: CALCITE-6397 > URL: https://issues.apache.org/jira/browse/CALCITE-6397 > Project: Calcite > Issue Type: New Feature >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > Add NVL2 function (enabled in Spark library) > > https://spark.apache.org/docs/2.3.0/api/sql/index.html#nvl2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6396) Add ADD_MONTHS function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6396: Labels: pull-request-available (was: ) > Add ADD_MONTHS function (enabled in Spark library) > -- > > Key: CALCITE-6396 > URL: https://issues.apache.org/jira/browse/CALCITE-6396 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Add ADD_MONTHS function (enabled in Spark library) > > https://spark.apache.org/docs/2.3.0/api/sql/index.html#add_months -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6393) Byte code of SqlFunctions is invalid
[
https://issues.apache.org/jira/browse/CALCITE-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6393:
Labels: pull-request-available (was: )
> Byte code of SqlFunctions is invalid
>
>
> Key: CALCITE-6393
> URL: https://issues.apache.org/jira/browse/CALCITE-6393
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> The issue is a result of testing of Apache Calcite 1.37.0 rc 4 in this thread
> [1]
> There is test project andprocedure provided by [~MasseGuillaume] [2] (see
> also original thread where this was first discussed [3])
> it shows that since Calcite 1.36.0 it starts failing as
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for
> length 297
> at org.objectweb.asm.ClassReader.readLabel(ClassReader.java:2695)
> at org.objectweb.asm.ClassReader.createLabel(ClassReader.java:2711)
> at
> org.objectweb.asm.ClassReader.readTypeAnnotations(ClassReader.java:2777)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:1929)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> at org.objectweb.asm.ClassReader.accept(ClassReader.java:745)
> {noformat}
> Also since Calcite 1.27.0 it starts failing as
> {noformat}
> java.lang.IllegalArgumentException: Invalid end label (must be visited
> first)
> at
> org.objectweb.asm.util.CheckMethodAdapter.checkLabel(CheckMethodAdapter.java:1453)
> at
> org.objectweb.asm.util.CheckMethodAdapter.visitLocalVariableAnnotation(CheckMethodAdapter.java:996)
> at
> org.objectweb.asm.MethodVisitor.visitLocalVariableAnnotation(MethodVisitor.java:757)
> at
> org.objectweb.asm.commons.MethodRemapper.visitLocalVariableAnnotation(MethodRemapper.java:257)
> at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2614)
> at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1515)
> {noformat}
> [1] https://lists.apache.org/thread/n6cs1l86mt6fc5q8pcxr97czs3p6w65f
> [2] https://github.com/MasseGuillaume/asm-remapper-bug
> [3] https://lists.apache.org/thread/o736wz4qnr4l285bj5gv073cy0qll9t0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6395) Significant precision loss when representing REAL literals
[
https://issues.apache.org/jira/browse/CALCITE-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6395:
Labels: pull-request-available (was: )
> Significant precision loss when representing REAL literals
> --
>
> Key: CALCITE-6395
> URL: https://issues.apache.org/jira/browse/CALCITE-6395
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Consider this test that could be a SqlOperatorTest:
> {code:java}
> f.checkScalar("CAST(CAST('36854775807.0' AS REAL) AS BIGINT)",
> "36854775808", "BIGINT NOT NULL");
> {code}
> The produced result is actually very far:
> Expected: is "36854775808"
> but: was "36854779904"
> This big error comes from two reasons:
> - Calcite uses BigDecimal values to represent floating point values, see
> [CALCITE-2067]
> - When converting a Float value to a BigDecimal in RexBuilder.clean(), the
> following sequence is used:
> {code:java}
> new BigDecimal(((Number) o).doubleValue(), MathContext.DECIMAL32)
> {code}
> Using a DECIMAL32 math context leads to the precision loss. Just because a
> Float uses 32 bits does not mean that the decimal should also use 32 bits.
> The real fix is in the PR for [CALCITE-2067], but that hasn't been reviewed
> for a long time, so I will submit a fix for the clean() method..
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6376) Filtering CTE of at least 6 columns with QUALIFY operation results in exception
[
https://issues.apache.org/jira/browse/CALCITE-6376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6376:
Labels: pull-request-available (was: )
> Filtering CTE of at least 6 columns with QUALIFY operation results in
> exception
> ---
>
> Key: CALCITE-6376
> URL: https://issues.apache.org/jira/browse/CALCITE-6376
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Austin Richardson
>Assignee: ShenDa
>Priority: Major
> Labels: pull-request-available
>
> Example query:
>
> {code:java}
> WITH MyCTE AS (
> SELECT
> column1,
> column2,
> column3,
> column4,
> column5,
> column6
> FROM (
> VALUES
> ('value1', 10, 5.0, 'data1', 'info1', 'test1'),
> ('value2', 20, 4.0, 'data2', 'info2', 'test2'),
> ('value3', 30, 3.0, 'data3', 'info3', 'test3'),
> ('value4', 40, 2.0, 'data4', 'info4', 'test4'),
> ('value5', 50, 1.0, 'data5', 'info5', 'test5')
> ) AS t(column1, column2, column3, column4, column5, column6)
> )
> SELECT *
> FROM MyCTE
> QUALIFY RANK() OVER (ORDER BY column3) = 1{code}
>
> And exception snippet:
>
> {code:java}
> Caused by: java.lang.ClassCastException: class
> org.apache.calcite.rex.RexInputRef cannot be cast to class
> java.lang.Comparable (org.apache.calcite.rex.RexInputRef is in unnamed module
> of loader org.springframework.boot.loader.LaunchedURLClassLoader @257f30f7;
> java.lang.Comparable is in module java.base of loader 'bootstrap')
> at
> org.apache.calcite.runtime.FlatLists$ComparableListImpl.get(FlatLists.java:1319)
> at
> org.apache.calcite.runtime.FlatLists$ComparableListImpl.get(FlatLists.java:1309)
> at
> java.base/java.util.AbstractList$Itr.next(AbstractList.java:373){code}
>
> Either removing one of the columns or the QUALIFY filter results in a
> successful query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6390) ArrowAdapterTest fails on Windows
[
https://issues.apache.org/jira/browse/CALCITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6390:
Labels: pull-request-available (was: )
> ArrowAdapterTest fails on Windows
> -
>
> Key: CALCITE-6390
> URL: https://issues.apache.org/jira/browse/CALCITE-6390
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Sergey Nuyanzin
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> -That's seems somehow highlights the difference between Windows Server and
> non Server-
> -we have tests against Windows Server on gha (windows-latest) and they are
> green-
> -At the same time local tests on Windows 11 show that {{ArrowAdapterTest}}
> fails like-
> Based on deeper analysis Arrow module was never tested on Windows since for
> Windows conf on gha it is {{--exclude-task :arrow:build}} which makes it
> skipping the tests for this module
> https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/.github/workflows/main.yml#L110C60-L110C88
> Any attempt to test it leads to
> {noformat}
> FAILURE 0.0sec, org.apache.calcite.adapter.arrow.ArrowAdapterTest >
> executionError
> java.io.IOException: Failed to delete temp directory
> D:\MyConfiguration\cancai.cai\AppData\Local\Temp\junit5105379620525559011.
> The following paths could not be deleted (see suppressed exceptions for
> details): , arrow
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.createIOExceptionWithAttachedFailures(TempDirectory.java:350)
> at
> org.junit.jupiter.engine.extension.TempDirectory$CloseablePath.close(TempDirectory.java:251)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.lambda$closeAllStoredCloseableValues$3(ExtensionValuesStore.java:68)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
> at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:483)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at
> org.junit.jupiter.engine.execution.ExtensionValuesStore.closeAllStoredCloseableValues(ExtensionValuesStore.java:68)
> at
> org.junit.jupiter.engine.descriptor.AbstractExtensionContext.close(AbstractExtensionContext.java:80)
> at
> org.junit.jupiter.engine.execution.JupiterEngineExecutionContext.close(JupiterEngineExecutionContext.java:53)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:222)
> at
> org.junit.jupiter.engine.descriptor.JupiterTestDescriptor.cleanUp(JupiterTestDescriptor.java:57)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$cleanUp$10(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.cleanUp(NodeTestTask.java:167)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:98)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService$ExclusiveTask.compute(ForkJoinPoolHierarchicalTestExecutorService.java:185)
> at
> org.junit.platform.engine.support.hierarchical.ForkJoinPoolHierarchicalTestExecutorService.invokeAll(ForkJoinPoolHierarchicalTestExecutorService.java:129)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
>
[jira] [Updated] (CALCITE-6388) PsTableFunction throws NumberFormatException when the 'user' column has spaces
[
https://issues.apache.org/jira/browse/CALCITE-6388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6388:
Labels: pull-request-available (was: )
> PsTableFunction throws NumberFormatException when the 'user' column has spaces
> --
>
> Key: CALCITE-6388
> URL: https://issues.apache.org/jira/browse/CALCITE-6388
> Project: Calcite
> Issue Type: Bug
> Components: os-adapter
>Affects Versions: 1.36.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Line parsing splits on spaces
> ([PsTableFunction.java#L77|https://github.com/apache/calcite/blob/aa8d81bf1ff39e3632aeb856fc4cc247ce9727e5/plus/src/main/java/org/apache/calcite/adapter/os/PsTableFunction.java#L77]),
> which breaks whenever the "user" contains at least a space.
> An example output on my laptop is as follows:
> {noformat}
> $ ps ax -o
> ppid=,pid=,pgid=,tpgid=,stat=,user=,pcpu=,pmem=,vsz=,rss=,tty=,start=,time=,uid=,ruid=,sess=,comm=
> | grep startup
> 1 6728 6728 0 S startup user 0.0 0.0 410266096 2528 ??
> 11Apr24 0:16.97 501 501 0 /usr/sbin/distnoted
> 1 6729 6729 0 SN startup user 0.0 0.1 410332256 17616 ??
> 11Apr24 0:42.41 501 501 0
> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdbulkimport
> 1 6750 6750 0 S startup user 0.0 0.0 410376144 13344 ??
> 11Apr24 0:40.39 501 501 0 /usr/libexec/lsd
> 1 10148 10148 0 S startup user 0.0 0.0 410354816 5488 ??
> 8:26PM 0:00.31 501 501 0 /usr/libexec/containermanagerd
> 1 95313 95313 0 S startup user 0.0 0.0 410357344 6576 ??
> Fri05PM 0:00.32 501 501 0 /usr/libexec/trustd{noformat}
> When running the test it fails with the following stack trace:
> {code:java}
> Error while executing SQL "select distinct `user` from ps": while parsing
> value [user] of field [pcpu] in line [ 1 6728 6728 0 S startup
> user 0.0 0.0 410266096 2528 ?? 11Apr24 0:16.95 501 501
> 0 /usr/sbin/distnoted]
> java.sql.SQLException: Error while executing SQL "select distinct `user` from
> ps": while parsing value [user] of field [pcpu] in line [ 1 6728 6728
> 0 S startup user 0.0 0.0 410266096 2528 ?? 11Apr24
> 0:16.95 501 501 0 /usr/sbin/distnoted]
> 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.CalciteAssert.assertQuery(CalciteAssert.java:566)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1495)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1434)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1493)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1483)
> at
> org.apache.calcite.adapter.os.OsAdapterTest.testPsDistinct(OsAdapterTest.java:183)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> 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
>
[jira] [Updated] (CALCITE-6387) Calcite build while compiliation with jdk11+
[
https://issues.apache.org/jira/browse/CALCITE-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6387:
Labels: pull-request-available (was: )
> Calcite build while compiliation with jdk11+
>
>
> Key: CALCITE-6387
> URL: https://issues.apache.org/jira/browse/CALCITE-6387
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
>
> The issue appears with newly added Arrow adapter which requires
> {noformat}
> --add-opens=java.base/java.nio=ALL-UNNAMED
> {noformat}
> could be fixed with adding
> {noformat}
> plugins.withType {
> tasks {
> configureEach {
> jvmArgs("-XX:+IgnoreUnrecognizedVMOptions")
> jvmArgs("--add-opens=java.base/java.nio=ALL-UNNAMED")
> }
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6386) NPE when using ES adapter with model.json and no specified username, password or pathPrefix
[
https://issues.apache.org/jira/browse/CALCITE-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6386:
Labels: pull-request-available (was: )
> NPE when using ES adapter with model.json and no specified username, password
> or pathPrefix
> ---
>
> Key: CALCITE-6386
> URL: https://issues.apache.org/jira/browse/CALCITE-6386
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.36.0
>Reporter: guluo
>Priority: Major
> Labels: pull-request-available
>
> Reproduction steps：
> 1 Creating model.json, according to the calcite doc about [Elasticsearch
> adapter
> (apache.org)|https://calcite.apache.org/docs/elasticsearch_adapter.html]
> {
> "version": "1.0",
> "defaultSchema": "elasticsearch",
> "schemas": [
> {
> "type": "custom",
> "name": "elasticsearch",
> "factory":
> "org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory",
> "operand": {
> "coordinates": "\{'127.0.0.1': 9200}"
> }
> }
> ]
> }
>
> 2 Connecting es by sqlline
> sqlline> !connect jdbc:calcite:model=/root/build/calcite//model.json
>
> 3 We would get NPE,as follow.
> Caused by: java.lang.NullPointerException: at index 1
> at
> com.google.common.collect.ObjectArrays.checkElementNotNull(ObjectArrays.java:232)
> at
> com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:222)
> at
> com.google.common.collect.ObjectArrays.checkElementsNotNull(ObjectArrays.java:216)
> at
> com.google.common.collect.ImmutableList.construct(ImmutableList.java:354)
> at com.google.common.collect.ImmutableList.of(ImmutableList.java:128)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory.connect(ElasticsearchSchemaFactory.java:202)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchSchemaFactory.create(ElasticsearchSchemaFactory.java:176)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:275)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6383) The class SameOperandTypeChecker is incorrectly documented
[
https://issues.apache.org/jira/browse/CALCITE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6383:
Labels: pull-request-available (was: )
> The class SameOperandTypeChecker is incorrectly documented
> --
>
> Key: CALCITE-6383
> URL: https://issues.apache.org/jira/browse/CALCITE-6383
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The SameOperandTypeChecker claims that it checks whether operands have the
> same type (the class name suggests this, as does the JavaDoc).
> {code:java}
> /**
> * Parameter type-checking strategy where all operand types must be the same.
> */
> public class SameOperandTypeChecker implements SqlSingleOperandTypeChecker {
> {code}
> But the code does something this:
> {code:java}
> for (int i : operandList) {
> if (prev >= 0) {
> if (!SqlTypeUtil.isComparable(types[i], types[prev])) {
> {code}
> The documentation for isComparable says:
> {code:java}
> /**
>* Returns whether two types are comparable. They need to be scalar types of
>* the same family, or struct types whose fields are pairwise comparable.
> {code}
> Thus the class only checks that the operands have the same type *family*, not
> the same *type*.
> I am not sure what the right fix is, though, since changing the class name
> would be a pretty big breaking change. But I suspect this confusion is a
> source of a few bugs. An instance is [CALCITE-6382]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6358) Support all PostgreSQL 14 date/time patterns
[ https://issues.apache.org/jira/browse/CALCITE-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6358: Labels: pull-request-available (was: ) > Support all PostgreSQL 14 date/time patterns > > > Key: CALCITE-6358 > URL: https://issues.apache.org/jira/browse/CALCITE-6358 > Project: Calcite > Issue Type: Sub-task >Reporter: Norman Jordan >Priority: Minor > Labels: pull-request-available > > Many of the date/time format patterns supported by PostgreSQL 14 are not > supported in Calcite. > * HH > * US > * > * S > * AM > * A.M. > * am > * a.m. > * PM > * P.M. > * pm > * p.m. > * Y,YYY > * YYY > * Y > * IYYY > * IYY > * IY > * I > * BC > * B.C. > * bc > * b.c. > * AD > * A.D. > * ad > * a.d. > * MONTH > * month > * MON > * mon > * DAY > * day > * Dy > * dy > * IDDD > * ID > * TZH > * TZM > * OF > There are also template pattern modifiers that need to be supported. > * FM (prefix) > * TH (suffix) > * th (suffix) > * FX (prefix) > * TM (prefix) > Some format patterns in Calcite behave differently from PostgreSQL 14. > * FF1 > * FF2 > * FF4 > * FF5 > * FF6 > Also verify that the other existing format strings produce results that match > PostgreSQL 14. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6385) LintTest fails when run in source distribution
[
https://issues.apache.org/jira/browse/CALCITE-6385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6385:
Labels: pull-request-available (was: )
> LintTest fails when run in source distribution
> --
>
> Key: CALCITE-6385
> URL: https://issues.apache.org/jira/browse/CALCITE-6385
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.36.0
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
>
> Steps to reproduce:
> # Download
> [https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.37.0-rc0/apache-calcite-1.37.0-src.tar.gz]
> # tar -xvf apache-calcite-1.37.0-src.tar.gz
> # cd apache-calcite-1.37.0-src
> # /opt/gradle/gradle-7.6.1/bin/gradle cleanTest :core:test --tests LintTest
> {noformat}
> FAILURE 0.1sec, org.apache.calcite.test.LintTest >
> testContributorsFileIsSorted()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at
> org.apache.calcite.test.LintTest.testContributorsFileIsSorted(LintTest.java:400)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.0sec, org.apache.calcite.test.LintTest > testMailmapFile()
> java.lang.RuntimeException: command [git, ls-files, *.bat, *.cmd, *.csv,
> *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts, .mailmap, *.md,
> *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]: failed with exception
> at org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:185)
> at
> org.apache.calcite.util.TestUnsafe.getTextFiles(TestUnsafe.java:158)
> at org.apache.calcite.test.LintTest.testMailmapFile(LintTest.java:419)
> Caused by: java.lang.RuntimeException: command [git, ls-files, *.bat,
> *.cmd, *.csv, *.fmpp, *.ftl, *.iq, *.java, *.json, *.jj, *.kt, *.kts,
> .mailmap, *.md, *.properties, *.sh, *.sql, *.txt, *.xml, *.yaml, *.yml]:
> exited with status 128
> at
> org.apache.calcite.util.TestUnsafe.getGitFiles(TestUnsafe.java:180)
> ... 2 more
> FAILURE 0.1sec,6 completed, 2 failed, 2 skipped,
> org.apache.calcite.test.LintTest
> {noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6365) Support for RETURNING clause of JSON_QUERY
[
https://issues.apache.org/jira/browse/CALCITE-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6365:
Labels: pull-request-available (was: )
> Support for RETURNING clause of JSON_QUERY
> --
>
> Key: CALCITE-6365
> URL: https://issues.apache.org/jira/browse/CALCITE-6365
> Project: Calcite
> Issue Type: New Feature
>Reporter: Dawid Wysakowicz
>Priority: Major
> Labels: pull-request-available
>
> SQL standard says {{JSON_QUERY}} should support {{RETURNING}} clause similar
> to {{JSON_VALUE}}. Calcite supports the clause for JSON_VALUE already, but
> not for the JSON_QUERY.
> {code}
> ::=
> JSON_QUERY
>
> [ ]
> [ WRAPPER ]
> [ QUOTES [ ON SCALAR STRING ] ]
> [ ON EMPTY ]
> [ ON ERROR ]
>
> ::=
> RETURNING
> [ FORMAT ]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6384) Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml
[ https://issues.apache.org/jira/browse/CALCITE-6384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6384: Labels: pull-request-available (was: ) > Missing ASF header from buildcache.yml, gradle-wrapper-validation.yml > - > > Key: CALCITE-6384 > URL: https://issues.apache.org/jira/browse/CALCITE-6384 > Project: Calcite > Issue Type: Task >Affects Versions: 1.36.0 >Reporter: Stamatis Zampetakis >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > > The header is required as per [ASF > policy|https://www.apache.org/legal/src-headers.html]. > * > [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/buildcache.yml] > * > [https://github.com/apache/calcite/blob/153494207c24318d4c1d2c908df4a15c4aa4/.github/workflows/gradle-wrapper-validation.yml] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6382) Type inference for SqlLeadLagAggFunction is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6382: Labels: pull-request-available (was: ) > Type inference for SqlLeadLagAggFunction is incorrect > - > > Key: CALCITE-6382 > URL: https://issues.apache.org/jira/browse/CALCITE-6382 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > Currently the LeadLag operator does not use the default value when inferring > the type of a column. > For the following example: > ``` > SELECT lead(c * 2, 1, -1.4) OVER (PARTITION BY x ORDER BY c) FROM t > ``` > The column 'c' has type INTEGER, and Calcite infers a type of INTEGER for the > result. However, the default value for the lead is -1.4, which is DECIMAL, so > the result type should be DECIMAL. > Currently Calcite only uses the nullability of the default value, but not its > type in the result type inference. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6302) Release Calcite 1.37.0
[ https://issues.apache.org/jira/browse/CALCITE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6302: Labels: pull-request-available (was: ) > Release Calcite 1.37.0 > -- > > Key: CALCITE-6302 > URL: https://issues.apache.org/jira/browse/CALCITE-6302 > Project: Calcite > Issue Type: Task >Reporter: Sergey Nuyanzin >Assignee: Sergey Nuyanzin >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > Releasing Calcite 1.37.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6378) Since docker 26.x pushing and pulling with image manifest v2 schema 1 is disabled by default
[
https://issues.apache.org/jira/browse/CALCITE-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6378:
Labels: pull-request-available (was: )
> Since docker 26.x pushing and pulling with image manifest v2 schema 1 is
> disabled by default
>
>
> Key: CALCITE-6378
> URL: https://issues.apache.org/jira/browse/CALCITE-6378
> Project: Calcite
> Issue Type: Bug
>Reporter: Sergey Nuyanzin
>Assignee: Sergey Nuyanzin
>Priority: Critical
> Labels: pull-request-available
>
> the source [1] also tells that it is going to be removed.
> In Calcite it comes together with redis adapter which uses pretty old redis
> docker image (2.8.19)
> {noformat}
> ./gradlew clean build
> {noformat}
> is enough to reproduce (assuming there is docker 26+)
> The fix is pretty straightforward: bumping docker image to e.g. 7.2.4 helps
> [1]
> https://docs.docker.com/engine/deprecated/#pushing-and-pulling-with-image-manifest-v2-schema-1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6361) Uncollect.deriveUncollectRowType crashes if the input data is not a collection
[ https://issues.apache.org/jira/browse/CALCITE-6361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6361: Labels: pull-request-available (was: ) > Uncollect.deriveUncollectRowType crashes if the input data is not a collection > -- > > Key: CALCITE-6361 > URL: https://issues.apache.org/jira/browse/CALCITE-6361 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > This happens because the type checker calls getComponentType() without > checking first that the field type has components. It should report an error > in such a case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6377) Time expression causes IllegalStateException
[
https://issues.apache.org/jira/browse/CALCITE-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6377:
Labels: pull-request-available (was: )
> Time expression causes IllegalStateException
>
>
> Key: CALCITE-6377
> URL: https://issues.apache.org/jira/browse/CALCITE-6377
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following SqlOperatorTest causes an exception:
> {code:java}
> final SqlOperatorFixture f = fixture();
> f.checkScalar("time '12:03:01' + interval '25' day",
> "12:03:01", "TIME(0) NOT NULL");
> {code}
> The exception is:
> {code}
> Caused by: java.lang.IllegalStateException: Unable to implement
> EnumerableCalc(expr#0=[{inputs}], expr#1=[12:03:01],
> expr#2=[216000:INTERVAL DAY], expr#3=[+($t1, $t2)], EXPR$0=[$t3]):
> rowcount = 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0
> rows, 1.0 cpu, 0.0 io}, id = 13
> at
> org.apache.calcite.adapter.enumerable.EnumerableRelImplementor.implementRoot(EnumerableRelImplementor.java:117)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:112)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1171)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:326)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:666)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:519)
> ...
> Suppressed: java.lang.ArithmeticException: Value 216000 out of range
> at
> org.apache.calcite.linq4j.tree.Primitive.checkRoundedRange(Primitive.java:383)
> at
> org.apache.calcite.linq4j.tree.Primitive.numberValue(Primitive.java:412)
> at
> org.apache.calcite.linq4j.tree.Expressions.constant(Expressions.java:575)
> at
> org.apache.calcite.linq4j.tree.OptimizeShuttle.visit(OptimizeShuttle.java:305)
> at
> org.apache.calcite.linq4j.tree.UnaryExpression.accept(UnaryExpression.java:39)
> at
> org.apache.calcite.linq4j.tree.BinaryExpression.accept(BinaryExpression.java:47)
> {code}
> This seems to happen because the implementation insists in evaluating the
> expression by converting the 25 days interval to milliseconds, which
> overflows. However, adding a days interval to a time should be a noop.
> Replacing 'days' with 'months', for example, works fine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6169) EnumUtils.convert does not implement the correct SQL cast semantics
[ https://issues.apache.org/jira/browse/CALCITE-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6169: Labels: pull-request-available (was: ) > EnumUtils.convert does not implement the correct SQL cast semantics > --- > > Key: CALCITE-6169 > URL: https://issues.apache.org/jira/browse/CALCITE-6169 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > The code generated by EnumUtil for casts uses the Java semantics, where casts > just truncate values. The SQL semantics requires a runtime exception if the > value does not fit in the target datatype. > Some of the bugs in this code generator are masked by the BlockBuilder > optimizer which attempts to optimize the generated code using the SQL > semantics... But if the code is not optimized and is executed in Java it > generates wrong results for most conversions that overflow. > One additional wrinkle is that it is not entirely clear whether the bug is in > EnumUtils or in the code that invokes EnumUtils. It is not specified which of > the two semantics for casts EnumUtils are supposed to implement: Java or SQL? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5289) Assertion failure in MultiJoinOptimizeBushyRule
[
https://issues.apache.org/jira/browse/CALCITE-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5289:
Labels: pull-request-available (was: )
> Assertion failure in MultiJoinOptimizeBushyRule
> ---
>
> Key: CALCITE-5289
> URL: https://issues.apache.org/jira/browse/CALCITE-5289
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mou Wu
>Priority: Minor
> Labels: pull-request-available
>
> The reproduction is easy: just modify the following test case from
> PlannerTest.java:
>
> — a/core/src/test/java/org/apache/calcite/tools/PlannerTest.java
> +++ b/core/src/test/java/org/apache/calcite/tools/PlannerTest.java
> {}@@ -1005,7 +1005,7 @@ private void checkJoinNWay(int n) throws
> Exception {{}
> {{private void checkHeuristic(String sql, String expected) throws Exception
> {}}
> {{ Planner planner = getPlanner(null,}}
> {{- Programs.heuristicJoinOrder(Programs.RULE_SET, false, 0));}}
> {{+ Programs.heuristicJoinOrder(Programs.RULE_SET, true, 0));}}
> {{ SqlNode parse = planner.parse(sql);}}
> {{ SqlNode validate = planner.validate(parse);}}
> {{ RelNode convert = planner.rel(validate).rel;}}
>
> Then the test fails with the exception shown below. This happens with the
> latest version of calcite, the main branch.
> It looks like the rule does not account for the fact that outer joins can
> produce results with a different nullability than the input relations.
> The exception can be triggered even for very simple outer join queries, e.g.:
> SELECT T1.COL3 FROM T AS T1 LEFT JOIN T AS T2 ON T1.COL1 = T2.COL5
>
> The only workaround I found is to make sure this rule is never applied when a
> query contains an outer join.
>
> Here is the Java stack trace:
> {{java.lang.RuntimeException: Error while applying rule
> MultiJoinOptimizeBushyRule, args
> [rel#44:MultiJoin.NONE.[](input#0=RelSubset#42,input#1=RelSubset#43,joinFilter=true,isFullOuterJoin=false,joinTypes=[RIGHT,
> INNER],outerJoinConditions=[=($0, $10), NULL],projFields=[ALL, ALL])]}}
>
> {{ at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:250)}}
> {{ at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:59)}}
> {{ at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)}}
> {{ at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:318)}}
> {{ at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:337)}}
> {{ at
> org.apache.calcite.tools.Programs.lambda$heuristicJoinOrder$1(Programs.java:223)}}
> {{ at
> org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:373)}}
> {{ at
> org.apache.calcite.tools.PlannerTest.checkHeuristic(PlannerTest.java:1014)}}
> {{ at
> org.apache.calcite.tools.PlannerTest.testHeuristicRightJoin(PlannerTest.java:1003)}}
> {{ 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:725)}}
> {{ 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:149)}}
> {{ at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)}}
> {{ at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)}}
> {{ at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)}}
> {{ at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)}}
> {{ at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)}}
> {{ at
>
[jira] [Updated] (CALCITE-6313) Add POWER function for PostgreSQL
[ https://issues.apache.org/jira/browse/CALCITE-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6313: Labels: pull-request-available (was: ) > Add POWER function for PostgreSQL > - > > Key: CALCITE-6313 > URL: https://issues.apache.org/jira/browse/CALCITE-6313 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > * Our existing implementation always returns double. > * PostgreSQL allows returning a numeric instead of a double when inputs are > numeric. Not sure if this makes sense though. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6269) Fix missing/broken BigQuery date-time format elements
[
https://issues.apache.org/jira/browse/CALCITE-6269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6269:
Labels: pull-request-available (was: )
> Fix missing/broken BigQuery date-time format elements
> -
>
> Key: CALCITE-6269
> URL: https://issues.apache.org/jira/browse/CALCITE-6269
> Project: Calcite
> Issue Type: Bug
>Reporter: Jerin John
>Assignee: Jerin John
>Priority: Minor
> Labels: pull-request-available
>
> Calcite has the
> [FormatModels|https://github.com/apache/calcite/blob/2dadcd1a0e235f5fe1b29c9c32014035971fd45e/core/src/main/java/org/apache/calcite/util/format/FormatModels.java#L115]
> class which is missing support for or has incorrect implementation for the
> following DATE-TIME format elements:
> * [YYY /
> Y|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_year_as_string]
> - last three or 1 digits of year
> *
> [|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_year_as_string]
> - supports four or more digits in the year, Calcite using
> [DateString|https://github.com/apache/calcite/blob/3326475c766267d521330006cc80730c4e456191/core/src/main/java/org/apache/calcite/util/DateString.java]
> util throws:
> {{java.lang.IllegalArgumentException: Year out of range: [12018]}}
> *
> [MONTH|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_month_as_string]
> formats to "Jan" instead of "JANUARY"
> *
> [S|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_second_as_string]
> - seconds of the day (5 digits), only SS is available that gives seconds of
> the minute.
> * [FFn
> (n=1/2)|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_second_as_string]
> - always returns seconds with precision 3 (=FF3); also BQ supports n=1-9,
> calcite format models supports n=1-6, should we expand this range?
> *
> [AM/PM|https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_meridian_as_string]
> - Meridian formats not available
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6363) Introduce a rule to derive more filters from inner join condition
[
https://issues.apache.org/jira/browse/CALCITE-6363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6363:
Labels: pull-request-available (was: )
> Introduce a rule to derive more filters from inner join condition
> -
>
> Key: CALCITE-6363
> URL: https://issues.apache.org/jira/browse/CALCITE-6363
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: ruanhui
>Priority: Minor
> Labels: pull-request-available
>
> Sometimes we can infer more predicates from inner Join , for example, in the
> query
> SELECT * FROM ta INNER JOIN tb ON ta.x = tb.y WHERE ta.x > 10
> we can infer condition tb.y > 10 and we can push it down to the table tb.
> In this way, it is possible to reduce the amount of data involved in the Join.
> To achieve this, here is my idea.
> The core data strucature is two Multimap:
> predicateMap : a map for inputRef to corresponding predicate such as: $1 ->
> [$1 > 10, $1 < 20, $1 = $2]
> equivalenceMap : a map for inputRef to corresponding equivalent values or
> inputRefs such as: $1 -> [$2, 1]
> The filter derivation is divided into 4 steps:
> 1. construct predicate map and equivalence map by traversing all conjunctions
> in the condition
> 2. search map and rewrite predicates with equivalent inputRefs or literals
> 2.1 find all inputRefs that are equivalent to the current inputRef, and then
> rewrite all predicates involving equivalent inputRefs using inputRef, for
> example if we have inputRef $1 = equivInputRef $2, then we can rewrite \{$2 =
> 10} to \{$1 = 10}.
> 2.2 find all predicates involving current inputRef. If any predicate refers
> to another inputRef, rewrite the predicate with the literal/constant
> equivalent to that inputRef, such as: if we have inputRef \{$1 > $2} and \{$2
> = 10} then we can infer new condition \{$1 > 10}.
> 2.3 derive new predicates based on equivalence relation in equivalenceMultimap
> 3. compose all original predicates and derived predicates
> 4. simplify expression such as range merging, like \{$1 > 10 AND $1 > 20} =>
> \{$1 > 20}, \{$1 > $2 AND $1 > $2} => \{$1 > $2}
> Anyone interested in this, please feel free to comment on this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6340) RelBuilder always creates Project with Convention.NONE during aggregate_
[
https://issues.apache.org/jira/browse/CALCITE-6340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6340:
Labels: pull-request-available (was: )
> RelBuilder always creates Project with Convention.NONE during aggregate_
>
>
> Key: CALCITE-6340
> URL: https://issues.apache.org/jira/browse/CALCITE-6340
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Adam Kennedy
>Assignee: James Duong
>Priority: Major
> Labels: pull-request-available
>
> In the RelBuilder method aggregate_, when (config.pruneInputOfAggregate() &&
> r instanceof Project) line 2443 the Project will be rewritten to remove
> unused columns.
> When this happens, the new Project will be created with the following line
> {{{}2487: r =
> {}}}{{{}2488: project.copy(cluster.traitSet(), project.getInput(),
> newProjects,{}}}
> {{2489: builder.build());}}
>
> The use of cluster.traitSet() returns emptyTraitSet which is always going to
> use Convention.NONE regardless of the Rebuilder's ProjectFactory.
> In the case of a query plan using a non-Logical convention FOO, with
> FooProject nodes that require the FOO convention, RelBuilder will normally
> happily produce FooProject nodes with FOO convention, allowing many CoreRules
> to be easily reused for custom Conventions.
> However, while RelBuilder will produce FooProject with FOO convention in the
> majority of cases, for the one specific case of column pruning a Project
> input to an aggregate, it will instead product a FooProject with NONE
> convention.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6359) Update GitHub Actions workflows to use docker compose v2
[ https://issues.apache.org/jira/browse/CALCITE-6359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6359: Labels: pull-request-available (was: ) > Update GitHub Actions workflows to use docker compose v2 > > > Key: CALCITE-6359 > URL: https://issues.apache.org/jira/browse/CALCITE-6359 > Project: Calcite > Issue Type: Task > Components: avatica, avatica-go, core >Reporter: Francis Chuang >Assignee: Francis Chuang >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0, avatica-go-5.4.0, avatica-1.26.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6356) Upgrade Calcite to Avatica 1.25.0
[
https://issues.apache.org/jira/browse/CALCITE-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6356:
Labels: pull-request-available (was: )
> Upgrade Calcite to Avatica 1.25.0
> -
>
> Key: CALCITE-6356
> URL: https://issues.apache.org/jira/browse/CALCITE-6356
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sergey Nuyanzin
>Priority: Major
> Labels: pull-request-available
>
> Upgrade Calcite to Avatica 1.25.0
> Also, as mentioned in comments for CALCITE-6053
> {quote}
> When the upgrade happens there are going to be some test failures in
> SqlOperatorTest (CALCITE-5923) highlighting the part of the code that needs
> to be updated. We left some comments to aid the cleanup.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6355) RelToSqlConverter[ORDER BY] generates an incorrect order by when NULLS LAST is used in non-projected field
[
https://issues.apache.org/jira/browse/CALCITE-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6355:
Labels: pull-request-available (was: )
> RelToSqlConverter[ORDER BY] generates an incorrect order by when NULLS LAST
> is used in non-projected field
> --
>
> Key: CALCITE-6355
> URL: https://issues.apache.org/jira/browse/CALCITE-6355
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Bruno Volpato
>Priority: Minor
> Labels: pull-request-available
>
>
> We are using RelToSqlConverter, and seeing issues with it generating invalid
> queries when using _DESC NULLS LAST,_ specifically.
>
> For example, this test query:
>
> {code:java}
> select "product_id"
> from "product"
> where "net_weight" is not null
> group by "product_id"
> order by MAX("net_weight") desc {code}
> Gets resolved correctly, with a subquery, to:
>
> {code:java}
> SELECT "product_id"
> FROM (SELECT "product_id", MAX("net_weight") AS "EXPR$1"
> FROM "foodmart"."product"
> WHERE "net_weight" IS NOT NULL
> GROUP BY "product_id"
> ORDER BY 2 DESC) AS "t3" {code}
>
>
> However, if I specify `desc nulls last`:
>
> {code:java}
> select "product_id"
> from "product"
> where "net_weight" is not null
> group by "product_id"
> order by MAX("net_weight") desc nulls last {code}
> It creates an invalid query (order by 2, but only one field was projected):
>
>
> {code:java}
> SELECT "product_id"
> FROM "foodmart"."product"
> WHERE "net_weight" IS NOT NULL
> GROUP BY "product_id"
> ORDER BY 2 DESC NULLS LAST {code}
>
>
>
> Trying to troubleshoot it, it appears that without the `NULLS LAST`, we have
> the following instance:
>
> {code:java}
> SqlBasicCall -> SqlNumericLiteral {code}
>
>
> But when including it, it gets wrapped in another call:
>
> {code:java}
> SqlBasicCall -> SqlBasicCall -> SqlNumericLiteral {code}
>
>
> So the [hasSortByOrdinal
> method|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L1938C21-L1958]
> ends up returning {_}false{_}, which causes `needNewSubQuery` to incorrectly
> report _false_ too.
>
> It appears that the best way to deal with this is by using a recursion to
> find numeric literals - but let me know if there are better ideas.
>
> I plan to take a stab at this since I got enough context.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6315) Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP
[ https://issues.apache.org/jira/browse/CALCITE-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6315: Labels: pull-request-available (was: ) > Support PostgreSQL TO_CHAR, TO_DATE, TO_TIMESTAMP > - > > Key: CALCITE-6315 > URL: https://issues.apache.org/jira/browse/CALCITE-6315 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > Labels: pull-request-available > > PostgreSQL supports different format strings than the version we have > implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6353) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS crashes while optimizing ARRAY_CONCAT expression
[
https://issues.apache.org/jira/browse/CALCITE-6353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6353:
Labels: pull-request-available (was: )
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS crashes while optimizing
> ARRAY_CONCAT expression
> --
>
> Key: CALCITE-6353
> URL: https://issues.apache.org/jira/browse/CALCITE-6353
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following RelOptRulesTest
> {code:java}
> @Test void testArrayConcat() {
> final String sql = "select array_concat(ARRAY [1, 2], ARRAY [3, 4])";
> sql(sql).withFactory(
> t -> t.withOperatorTable(
> opTab ->
> SqlLibraryOperatorTableFactory.INSTANCE.getOperatorTable(
> SqlLibrary.STANDARD, SqlLibrary.BIG_QUERY)))
> .withRule(CoreRules.PROJECT_REDUCE_EXPRESSIONS)
> .check();
> }
> {code}
> crashes with the following stack trace:
> {code:java}
> java.lang.RuntimeException: While compiling [ARRAY_CONCAT(ARRAY(1, 2),
> ARRAY(3, 4))]
> at org.apache.calcite.rex.RexExecutable.compile(RexExecutable.java:73)
> at org.apache.calcite.rex.RexExecutable.(RexExecutable.java:53)
> at
> org.apache.calcite.rex.RexExecutorImpl.reduce(RexExecutorImpl.java:145)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressionsInternal(ReduceExpressionsRule.java:774)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule.reduceExpressions(ReduceExpressionsRule.java:714)
> {code}
> It seems that the generated code passed to Janino is invalid:
> Line 10, Column 5: Assignment conversion not possible from type
> "java.util.ArrayList" to type "java.lang.Object[]"
> org.codehaus.commons.compiler.CompileException: Line 10, Column 5: Assignment
> conversion not possible from type "java.util.ArrayList" to type
> "java.lang.Object[]"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6332) Optimization CoreRules.AGGREGATE_EXPAND_DISTINCT_AGGREGATES_TO_JOIN produces incorrect results for aggregates with groupSets
[
https://issues.apache.org/jira/browse/CALCITE-6332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6332:
Labels: pull-request-available (was: )
> Optimization CoreRules.AGGREGATE_EXPAND_DISTINCT_AGGREGATES_TO_JOIN produces
> incorrect results for aggregates with groupSets
>
>
> Key: CALCITE-6332
> URL: https://issues.apache.org/jira/browse/CALCITE-6332
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The optimization rule does not seem to consider the groupSets at all.
> The following two queries produce the same resulting plan:
> {code:sql}
> select count(distinct deptno) as cd, count(*) as c
> from emp
> group by cube(deptno)
> {code}
> {code:sql}
> select count(distinct deptno) as cd, count(*) as c
> from emp
> group by deptno
> {code}
> (Notice that one query has a cube, while the other one doesn't)
> The produced plan is:
> {code}
> LogicalProject(CD=[$1], C=[$2]), id = 196
> LogicalAggregate(group=[{0}], CD=[COUNT($0)], C=[$SUM0($1)]), id = 201
> LogicalAggregate(group=[{0}], C=[COUNT()]), id = 198
> LogicalProject(DEPTNO=[$8]), id = 192
> LogicalTableScan(table=[[schema, EMP]]), id = 163
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6285) Function ARRAY_INSERT produces an incorrect result for negative indices
[
https://issues.apache.org/jira/browse/CALCITE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6285:
Labels: pull-request-available (was: )
> Function ARRAY_INSERT produces an incorrect result for negative indices
> ---
>
> Key: CALCITE-6285
> URL: https://issues.apache.org/jira/browse/CALCITE-6285
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Here is a test taken from the Spark documentation page:
> https://spark.apache.org/docs/latest/api/sql/index.html#array_insert
> {code}
> SELECT array_insert(array(5, 3, 2, 1), -4, 4);
> [5,4,3,2,1]
> {code}
> The result produced by Calcite is:
> [4,5,3,2,1]
> The strange thing is that there are tests for negative indices. I wonder if
> the original tests are wrong, or the behavior of this function in Spark was
> changed since the tests were written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6349) CoreRules.PROJECT_REDUCE_EXPRESSIONS crashes on expression with ARRAY_REPEAT
[
https://issues.apache.org/jira/browse/CALCITE-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6349:
Labels: pull-request-available (was: )
> CoreRules.PROJECT_REDUCE_EXPRESSIONS crashes on expression with ARRAY_REPEAT
>
>
> Key: CALCITE-6349
> URL: https://issues.apache.org/jira/browse/CALCITE-6349
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following test in RelOptRulesTest causes a crash:
> {code:java}
> @Test void testArrayRepeat() {
> final String sql = "select array_repeat(1, null)";
> sql(sql)
> .withFactory(
> t -> t.withOperatorTable(
> opTab ->
> SqlLibraryOperatorTableFactory.INSTANCE.getOperatorTable(
> SqlLibrary.STANDARD, SqlLibrary.SPARK)))
> .withRule(CoreRules.PROJECT_REDUCE_EXPRESSIONS)
> .check();
> }
> {code}
> The crash is:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(INTEGER NOT NULL ARRAY NOT NULL EXPR$0) NOT NULL
> expression type is RecordType(INTEGER NOT NULL ARRAY EXPR$0) NOT NULL
> set is rel#4:LogicalProject.(input=HepRelVertex#3,exprs=[ARRAY_REPEAT(1,
> null:DECIMAL(19, 9))])
> expression is LogicalProject(EXPR$0=[null:INTEGER NOT NULL ARRAY])
> LogicalValues(tuples=[[{ 0 }]])
> Type mismatch:
> rowtype of original rel: RecordType(INTEGER NOT NULL ARRAY NOT NULL EXPR$0)
> NOT NULL
> rowtype of new rel: RecordType(INTEGER NOT NULL ARRAY EXPR$0) NOT NULL
> Difference:
> EXPR$0: INTEGER NOT NULL ARRAY NOT NULL -> INTEGER NOT NULL ARRAY
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:419)
> at
> org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:60)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:273)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:288)
> at
> org.apache.calcite.rel.rules.ReduceExpressionsRule$ProjectReduceExpressionsRule.onMatch(ReduceExpressionsRule.java:317)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6348) ARRAY_OVERLAP with a NULL argument crashes the compiler
[
https://issues.apache.org/jira/browse/CALCITE-6348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6348:
Labels: pull-request-available (was: )
> ARRAY_OVERLAP with a NULL argument crashes the compiler
> ---
>
> Key: CALCITE-6348
> URL: https://issues.apache.org/jira/browse/CALCITE-6348
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following SqlOperatorTest:
> {code:java}
> f.checkScalar("arrays_overlap(null, null)", true,
> "NULL");
> {code}
> causes a crash:
> {code:java}
> at java.base/java.util.Objects.requireNonNull(Objects.java:222)
> at
> org.apache.calcite.sql.type.SqlTypeTransforms.lambda$static$6(SqlTypeTransforms.java:124)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:66)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:534)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:503)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:347)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6714)
> {code}
> This issue is similar to [CALCITE-6283]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6347) ARRAY_REPEAT with a string argument causes a compiler crash
[
https://issues.apache.org/jira/browse/CALCITE-6347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6347:
Labels: pull-request-available (was: )
> ARRAY_REPEAT with a string argument causes a compiler crash
> ---
>
> Key: CALCITE-6347
> URL: https://issues.apache.org/jira/browse/CALCITE-6347
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following SqlOperatorTest:
> {code:java}
> f.checkScalar("array_repeat('1', 2)", "['1', '1']",
> "CHAR(1) NOT NULL ARRAY NOT NULL");
> {code}
> causes a compiler error:
> {code}
> Error while compiling generated Java code:
> ...
> static final String
> $L4J$C$org_apache_calcite_runtime_SqlFunctions_repeat_1_2_ =
> org.apache.calcite.runtime.SqlFunctions.repeat("1", 2);
> ...
> at org.apache.calcite.avatica.Helper.wrap(Helper.java:37)
> at
> org.apache.calcite.adapter.enumerable.EnumerableInterpretable.toBindable(EnumerableInterpretable.java:128)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl$CalcitePreparingStmt.implement(CalcitePrepareImpl.java:1171)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:326)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:666)
> {code}
> This happens because the "repeat" function in SqlFunctions is overloaded to
> implement both ARRAY_REPEAT and REPEAT.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6345) Intervals with more than 100 years are not supported
[
https://issues.apache.org/jira/browse/CALCITE-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6345:
Labels: pull-request-available (was: )
> Intervals with more than 100 years are not supported
>
>
> Key: CALCITE-6345
> URL: https://issues.apache.org/jira/browse/CALCITE-6345
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Adding the following SqlValidatorTest:
> {code:java}
> expr("INTERVAL '100-2' YEAR TO MONTH").assertInterval(is(122L));
> {code}
> causes the following exception:
> {code}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 9 to
> line 1, column 38: Interval field value 100 exceeds precision of YEAR(2) field
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.fieldExceedsPrecisionException(SqlIntervalQualifier.java:1355)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.checkLeadFieldInRange(SqlIntervalQualifier.java:475)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.evaluateIntervalLiteralAsYearToMonth(SqlIntervalQualifier.java:626)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.evaluateIntervalLiteral(SqlIntervalQualifier.java:1293)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateLiteral(SqlValidatorImpl.java:3429)
> {code}
> The spec does not limit years to 2 digits, so I don't know where the YEAR(2)
> time is coming from.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6343) AS alias operator strips MEASUREness from measures
[
https://issues.apache.org/jira/browse/CALCITE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6343:
Labels: pull-request-available (was: )
> AS alias operator strips MEASUREness from measures
> --
>
> Key: CALCITE-6343
> URL: https://issues.apache.org/jira/browse/CALCITE-6343
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Barry Kelly
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> [CALCITE-5869|https://issues.apache.org/jira/browse/CALCITE-5869] introduced
> a change which removes MEASURE when inferring the return type when an
> operator is applied.
> The {{AS}} keyword for aliases is implemented as an operator in the SQL AST.
> Using {{AS}} removes MEASURE when typing expressions that have an alias in
> the {{SELECT}} clause.
> Thus, the type of {{SELECT m}} and {{SELECT m AS m}} are different when {{m}}
> is a measure. This is not desirable.
> Proposed fix: don't change type when using the {{AS}} operator.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6338) RelMdCollation#project can return an incomplete list of collations
[
https://issues.apache.org/jira/browse/CALCITE-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6338:
Labels: pull-request-available (was: )
> RelMdCollation#project can return an incomplete list of collations
> --
>
> Key: CALCITE-6338
> URL: https://issues.apache.org/jira/browse/CALCITE-6338
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
>
> {{RelMdCollation#project}} can return an incomplete list of collations.
> (I'll try to produce a unit test, for now I'll just describe the situation)
> Let us say we have a Project that projects the following expressions (notice
> that $2 will become $1 and $2 after the projection): $0, $2, $2, $3
> The Project's input has collation [2, 3]
> In order to calculate the Project's own collation, {{RelMdCollation#project}}
> will be called, and a MultiMap targets will be computed because, as in this
> case, a certain "source field" (e.g. 2) can have multiple project targets
> (e.g. 1 and 2). However, when the collation is being computed, *only the
> first target will be considered* (and the rest will be discarded):
> {code}
> public static @Nullable List project(RelMetadataQuery mq,
> RelNode input, List projects) {
> ...
> for (RelFieldCollation ifc : ic.getFieldCollations()) {
> final Collection integers = targets.get(ifc.getFieldIndex());
> if (integers.isEmpty()) {
> continue loop; // cannot do this collation
> }
> fieldCollations.add(ifc.withFieldIndex(integers.iterator().next()));
> // <-- HERE!!
> }
> {code}
> Because of this, the Project's collation will be [1 3], but there is also
> another valid one ([2 3]), so the correct (complete) result should be: [1 3]
> [2 3]
> This seems a minor problem, but it can be the root cause of more relevant
> issues. For instance, at the moment I have a scenario (not so easy to
> reproduce with a unit test) where a certain plan with a certain combination
> of rules in a HepPlanner results in a StackOverflow due to
> SortJoinTransposeRule being fired infinitely. The root cause is that, after
> the first application, the rule does not detect that the Join's left input is
> already sorted (due to the previous application of the rule), because there
> is a "problematic" Project on it (that shows the problem described above),
> which returns only one collation, whereas the second collation (the one being
> discarded) is the Sort's collation, so it would be one that would prevent the
> SortJoinTransposeRule from being re-applied over and over.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6337) Distinguish naked measure support between inside and outside aggregation
[
https://issues.apache.org/jira/browse/CALCITE-6337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6337:
Labels: pull-request-available (was: )
> Distinguish naked measure support between inside and outside aggregation
>
>
> Key: CALCITE-6337
> URL: https://issues.apache.org/jira/browse/CALCITE-6337
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Barry Kelly
>Priority: Major
> Labels: pull-request-available
>
> Measure type and AGGREGATE function (CALCITE-5105) introduced a configuration
> flag for naked measures.
> Naked measures are measure-typed columns that are referenced outside an
> {{AGGREGATE()}} function call.
> At Looker, we're trying to support a specific semantic using measure-typed
> columns:
> - selecting from a naked measure-typed column outside an aggregating query
> evaluates to {{NULL}}
> This permits basic introspection of the schema like `{{SELECT * FROM foo
> LIMIT 1}}`
> For this, we need naked measures outside a grouping context.
> - selecting from a naked measure-typed column inside an aggregating query is
> an error
> We want all expressions in a grouping query to either be part of the
> grouping key or to have
> an aggregation function applied. For this, we don't want naked measures
> inside a grouping context.
> This change proposes:
> - {{nakedMeasuresOutsideAggregatingQuery}} - boolean flag permitting measure
> references outside aggregating query
> - {{nakedMeasuresInsideAggregatingQuery}} - boolean flag permitting measure
> references inside aggregating query
> - deprecating {{nakedMeasures}} flag, which is now implemented by setting
> both of the above to the same value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6321) Add copy(List constants) method to Window class.
[ https://issues.apache.org/jira/browse/CALCITE-6321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6321: Labels: pull-request-available (was: ) > Add copy(List constants) method to Window class. > - > > Key: CALCITE-6321 > URL: https://issues.apache.org/jira/browse/CALCITE-6321 > Project: Calcite > Issue Type: Improvement >Reporter: Thomas D'Silva >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6333) Queries with distinct aggregations with filter throw NPE when planned using joins
[
https://issues.apache.org/jira/browse/CALCITE-6333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6333:
Labels: pull-request-available (was: )
> Queries with distinct aggregations with filter throw NPE when planned using
> joins
> -
>
> Key: CALCITE-6333
> URL: https://issues.apache.org/jira/browse/CALCITE-6333
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Abhishek Agarwal
>Priority: Major
> Labels: pull-request-available
>
> If I changed the test "testDistinctWithFilterWithoutGroupBy" and use the
> AGGREGATE_EXPAND_DISTINCT_AGGREGATES_TO_JOIN rule instead of
> AGGREGATE_EXPAND_DISTINCT_AGGREGATES
> {code:java}
> @Test void testDistinctWithFilterWithoutGroupBy() {
> final String sql = "SELECT SUM(comm), COUNT(DISTINCT sal) FILTER (WHERE
> sal > 1000)\n"
> + "FROM emp";
> sql(sql)
> .withRule(CoreRules.AGGREGATE_EXPAND_DISTINCT_AGGREGATES_TO_JOIN)
> .check();
> }
> {code}
> the test fails with the exception below
> {code:java}
> java.lang.NullPointerException: sourceOf.get(2)
> at java.base/java.util.Objects.requireNonNull(Objects.java:347)
> at
> org.apache.calcite.rel.rules.AggregateExpandDistinctAggregatesRule.doRewrite(AggregateExpandDistinctAggregatesRule.java:740)
> at
> org.apache.calcite.rel.rules.AggregateExpandDistinctAggregatesRule.onMatch(AggregateExpandDistinctAggregatesRule.java:260)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:337)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:556)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:420)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeRuleInstance(HepPlanner.java:243)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance$State.execute(HepInstruction.java:178)
> at
> org.apache.calcite.plan.hep.HepPlanner.lambda$executeProgram$0(HepPlanner.java:211)
> at
> com.google.common.collect.ImmutableList.forEach(ImmutableList.java:405)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:210)
> at
> org.apache.calcite.plan.hep.HepProgram$State.execute(HepProgram.java:118)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:205)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:191)
> at
> org.apache.calcite.test.RelOptFixture.checkPlanning(RelOptFixture.java:378)
> at org.apache.calcite.test.RelOptFixture.check(RelOptFixture.java:330)
> at org.apache.calcite.test.RelOptFixture.check(RelOptFixture.java:314)
> at
> org.apache.calcite.test.RelOptRulesTest.testDistinctWithFilterWithoutGroupBy(RelOptRulesTest.java:1462)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> 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.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> 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
>
[jira] [Updated] (CALCITE-6331) The third-party source code file doesn't have a License file.
[ https://issues.apache.org/jira/browse/CALCITE-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6331: Labels: pull-request-available (was: ) > The third-party source code file doesn't have a License file. > - > > Key: CALCITE-6331 > URL: https://issues.apache.org/jira/browse/CALCITE-6331 > Project: Calcite > Issue Type: Improvement >Reporter: Calvin Kirs >Priority: Major > Labels: pull-request-available > > [https://github.com/apache/calcite/blob/main/LICENSE#L184-L196] > We reference these third-party source code files but don't provide the > corresponding LICENSE files. > FYI : https://www.apache.org/legal/release-policy.html#license-file > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6322) Casts to DECIMAL types are ignored
[
https://issues.apache.org/jira/browse/CALCITE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6322:
Labels: pull-request-available (was: )
> Casts to DECIMAL types are ignored
> --
>
> Key: CALCITE-6322
> URL: https://issues.apache.org/jira/browse/CALCITE-6322
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> The following SqlOperatorTest fails:
> {code:java}
> f.checkScalar("CAST(1.123 AS DECIMAL(4, 0))", "1.0", "DECIMAL(4, 0) NOT
> NULL");
> {code}
> The result computed by Calcite is 1.123, ignoring the scale of the DECIMAL
> result.
> Spark, Postgres, MySQL all return 1.0.
> I have marked this as a major bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6325) Add LOG function (enabled in Mysql, Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6325: Labels: pull-request-available (was: ) > Add LOG function (enabled in Mysql, Spark library) > -- > > Key: CALCITE-6325 > URL: https://issues.apache.org/jira/browse/CALCITE-6325 > Project: Calcite > Issue Type: Sub-task >Reporter: Caican Cai >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6324) Type inferred for result of STDDEV, VAR_SAMP, etc. is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6324: Labels: pull-request-available (was: ) > Type inferred for result of STDDEV, VAR_SAMP, etc. is incorrect > --- > > Key: CALCITE-6324 > URL: https://issues.apache.org/jira/browse/CALCITE-6324 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > These functions are all use the same type inference algorithm, essentially > the algorithm used by AVG. > But if the values processed are decimal, STDDEV (and others) need much higher > precision to represent the result. (I am not sure that the inference is right > for integer types either, btw.) > This surfaced during the implementation of a fix for [CALCITE-6322]: if we > use the type inferred for these functions, the result overflows and causes a > runtime exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6309) Add REGEXP_LIKE function (enabled in Postgres library)
[ https://issues.apache.org/jira/browse/CALCITE-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6309: Labels: pull-request-available (was: ) > Add REGEXP_LIKE function (enabled in Postgres library) > -- > > Key: CALCITE-6309 > URL: https://issues.apache.org/jira/browse/CALCITE-6309 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Minor > Labels: pull-request-available > > * The Spark version of this is being implemented in CALCITE-6278 > * The PostgreSQL version requires supporting a 3-arg version that takes in > flags. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6323) Serialize return type during RelJson.toJson(RexNode node) for SqlKind.SAFE_CAST
[ https://issues.apache.org/jira/browse/CALCITE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6323: Labels: pull-request-available (was: ) > Serialize return type during RelJson.toJson(RexNode node) for > SqlKind.SAFE_CAST > --- > > Key: CALCITE-6323 > URL: https://issues.apache.org/jira/browse/CALCITE-6323 > Project: Calcite > Issue Type: Bug >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > > This is essentially the exact same as [CALCITE-5607] for > SqlKind.SAFE_CAST[1]. We need to preserve the desired cast type so that when > going from json->rex, we know what type we want to cast to. We do this for > the standard CAST, so we're really just trying to align the two functions. > [1] > https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L635 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6317) Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
[
https://issues.apache.org/jira/browse/CALCITE-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6317:
Labels: pull-request-available (was: )
> Optimization CoreRules.PROJECT_REDUCE_EXPRESSIONS is unsound
>
>
> Key: CALCITE-6317
> URL: https://issues.apache.org/jira/browse/CALCITE-6317
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> Here is a query taken from agg.iq:
> {code:sql}
> select deptno, gender, grouping_id(deptno, gender, deptno), count(*) as c
> from emp
> where deptno = 10
> group by rollup(gender, deptno)
> {code}
> The query plan initially is
> {code}
> LogicalProject(DEPTNO=[$1], GENDER=[$0], EXPR$2=[$2], C=[$3]), id = 72
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 71
> LogicalProject(GENDER=[$2], DEPTNO=[$1]), id = 70
> LogicalFilter(condition=[=($1, 10)]), id = 66
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> After applying PROJECT_REDUCE_EXPRESSIONS the plan looks like:
> {code}
> LogicalProject(DEPTNO=[CAST(10):INTEGER], GENDER=[$0], EXPR$2=[$2],
> C=[$3]), id = 82
> LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}, {}]],
> EXPR$2=[GROUPING_ID($1, $0, $1)], C=[COUNT()]), id = 78
> LogicalProject(GENDER=[$2], DEPTNO=[CAST(10):INTEGER]), id = 84
> LogicalFilter(condition=[=($1, 10)]), id = 74
> LogicalTableScan(table=[[schema, EMP]]), id = 65
> {code}
> The problem is in the outer LogicalProject, where the value 10 has replaced
> DEPTNO.
> However, DEPTNO can also be NULL, because of the groups in the
> LogicalAggregate.
> The constant should not be pushed past the aggregation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6319) Add negative test to pow and power functions
[ https://issues.apache.org/jira/browse/CALCITE-6319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6319: Labels: pull-request-available (was: ) > Add negative test to pow and power functions > > > Key: CALCITE-6319 > URL: https://issues.apache.org/jira/browse/CALCITE-6319 > Project: Calcite > Issue Type: Test >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Add negative test to pow and power functions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6300) Function map_values gives exception when inserted element type not equals map component type
[
https://issues.apache.org/jira/browse/CALCITE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6300:
Labels: pull-request-available (was: )
> Function map_values gives exception when inserted element type not equals map
> component type
>
>
> Key: CALCITE-6300
> URL: https://issues.apache.org/jira/browse/CALCITE-6300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> map_values(map('foo', cast (2 as tinyint), 'bar', 2)) {code}
> {code:java}
> java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
>at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109) at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers.java:321)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:14300)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160) at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:226)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:450)
>at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:225)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:229)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapValuesFunc(SqlOperatorTest.java:7276)
> 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
>
[jira] [Updated] (CALCITE-6314) Support PostgreSQL RANDOM
[ https://issues.apache.org/jira/browse/CALCITE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6314: Labels: pull-request-available (was: ) > Support PostgreSQL RANDOM > - > > Key: CALCITE-6314 > URL: https://issues.apache.org/jira/browse/CALCITE-6314 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Priority: Major > Labels: pull-request-available > > This is an alias for RAND(), except it should not support passing in a seed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6316) Update Javadoc for CALCITE-5607
[ https://issues.apache.org/jira/browse/CALCITE-6316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6316: Labels: pull-request-available (was: ) > Update Javadoc for CALCITE-5607 > --- > > Key: CALCITE-6316 > URL: https://issues.apache.org/jira/browse/CALCITE-6316 > Project: Calcite > Issue Type: Task >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Trivial > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6306) FILTER clauses for aggregate functions are not supported in MySQL, MariaDB and Starrocks
[
https://issues.apache.org/jira/browse/CALCITE-6306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6306:
Labels: pull-request-available (was: )
> FILTER clauses for aggregate functions are not supported in MySQL, MariaDB
> and Starrocks
>
>
> Key: CALCITE-6306
> URL: https://issues.apache.org/jira/browse/CALCITE-6306
> Project: Calcite
> Issue Type: Bug
>Reporter: hongyu guo
>Priority: Minor
> Labels: pull-request-available
>
> {code:sql}
> mysql> select sum(x) filter (where x = 1) from t;
> ERROR 1064 (42000): You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to use
> near '(where x = 1) from t' at line 1 {code}
> See details in https://modern-sql.com/feature/filter
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6301) Extend ‘Must-filter’ columns to support a conditional bypass list
[ https://issues.apache.org/jira/browse/CALCITE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6301: Labels: pull-request-available (was: ) > Extend ‘Must-filter’ columns to support a conditional bypass list > - > > Key: CALCITE-6301 > URL: https://issues.apache.org/jira/browse/CALCITE-6301 > Project: Calcite > Issue Type: Improvement >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Major > Labels: pull-request-available > > In CALCITE-6219 we introduced SemanticTable, where tables that implement this > interface can define fields to be ‘must-filter’, and a query without those > filters in any of its WHERE or HAVING clauses, it will throw a validation > error. > > I would like to extend this functionality to support a by-pass list of fields > such that if any field from this secondary list is present in a WHERE / > HAVING clause, then the must-filter fields can be ignored and will not raise > an exception if not filtered on. > > Ex. > > EMP table specifies the following: > Must-filter-fields: [EMPNO, DEPTNO] > Bypass-fields: [ENAME, SALARY] > > > SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error > SELECT * FROM EMP WHERE EMPNO = 1 -> Error > SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error > SELECT * FROM EMP WHERE ENAME = ’name’ -> No error > SELECT * FROM EMP WHERE SALARY > 10 -> No error > > > > Again, special considerations are for handling > > * Joins > * CTEs > * Subqueries > > > And a similar exhaustive suite of tests like the one for CALCITE-6219 should > be employed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6290) Incorrect return type for BigQuery TRUNC
[
https://issues.apache.org/jira/browse/CALCITE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6290:
Labels: pull-request-available (was: )
> Incorrect return type for BigQuery TRUNC
>
>
> Key: CALCITE-6290
> URL: https://issues.apache.org/jira/browse/CALCITE-6290
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
>
> The [BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#trunc]
> state that when the TRUNC function is provided an integer argument, it
> should return a double. However, we currently have the return type set to
> {{ARG0_NULLABLE}}. We should probably adjust this to
> {{ARG0_EXCEPT_INTEGER_NULLABLE}} similar to CALCITE-5747
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6259) The implementation of the Log library operator does not match the actual dialect behavior.
[
https://issues.apache.org/jira/browse/CALCITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6259:
Labels: pull-request-available (was: )
> The implementation of the Log library operator does not match the actual
> dialect behavior.
> --
>
> Key: CALCITE-6259
> URL: https://issues.apache.org/jira/browse/CALCITE-6259
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Attachments: 302662660-27b21670-5364-463c-b6dc-d750c46d7cd1.png,
> 302663876-91173a60-695d-409e-b325-3f91655c6d0d.png
>
>
> The implementation of the Log library operator does not match the actual
> dialect behavior.
> For example, when log10(0) returns null in mysql and spark, but log10(0)
> returns error in postgres, neither is calcite's -Intity
> {code:java}
> postgres=# select log10(0);
> ERROR: cannot take logarithm of zero
> postgres=# select log(2,0);
> ERROR: cannot take logarithm of zero
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6282) Avatica ignores time precision when returning TIME results
[
https://issues.apache.org/jira/browse/CALCITE-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6282:
Labels: pull-request-available (was: )
> Avatica ignores time precision when returning TIME results
> --
>
> Key: CALCITE-6282
> URL: https://issues.apache.org/jira/browse/CALCITE-6282
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> SqlOperatorTest contains the following disabled test:
> {code:java}
> f.checkScalar("cast(TIME '12:42:25.34' as TIME(2))",
> "12:42:25.34", "TIME(2) NOT NULL");
> {code}
> This test is disabled based on the following condition;
> {code:java}
> /**
>* Whether http://issues.eigenbase.org/browse/FRG-282;>issue
>* FRG-282: Support precision in TIME and TIMESTAMP data types is fixed.
>*/
> public static final boolean FRG282_FIXED = true;
> {code}
> However, the result is computed correctly. The precision is lost in the JDBC
> layer, which creates a TimeFromNumberAccessor which does not depend on the
> precision of the target type: it always returns the time with a precision of
> 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6283) Function array_append with a NULL array argument crashes with NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6283:
Labels: pull-request-available (was: )
> Function array_append with a NULL array argument crashes with
> NullPointerException
> --
>
> Key: CALCITE-6283
> URL: https://issues.apache.org/jira/browse/CALCITE-6283
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following test added to SqlOperatorTest:
> {code:java}
> f.checkNull("array_append(null, 2)");
> {code}
> causes Calcite to crash with the following stack trace:
> {code}
> java.lang.NullPointerException: componentType is null for NULL
> at java.base/java.util.Objects.requireNonNull(Objects.java:347)
> at
> org.apache.calcite.sql.type.NonNullableAccessors.getComponentTypeOrThrow(NonNullableAccessors.java:52)
> at
> org.apache.calcite.sql.type.ArrayElementOperandTypeChecker.checkOperandTypes(ArrayElementOperandTypeChecker.java:49)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:761)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:498)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:347)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6280) The Jetty's version number leak occurred while using the avatica http server
[
https://issues.apache.org/jira/browse/CALCITE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6280:
Labels: pull-request-available (was: )
> The Jetty's version number leak occurred while using the avatica http server
>
>
> Key: CALCITE-6280
> URL: https://issues.apache.org/jira/browse/CALCITE-6280
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Reporter: Vaibhav Joshi
>Assignee: Vaibhav Joshi
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unauthorised access to HTTP server using curl returns the Jerry server
> version. See sample response below
> {code:java}
>
>
>
> Error 401 Unauthorized
>
> HTTP ERROR 401 Unauthorized
>
> URI:/
> STATUS:401
> MESSAGE:Unauthorized
> SERVLET:-
>
> https://eclipse.org/jetty;>Powered by Jetty://
> 9.4.44.v20210927
>
> {code}
>
> For security reason, it's not advisable to return server version in the
> response.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6278) Add REGEXP function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6278: Labels: pull-request-available (was: ) > Add REGEXP function (enabled in Spark library) > -- > > Key: CALCITE-6278 > URL: https://issues.apache.org/jira/browse/CALCITE-6278 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Add Function > [REGEXP|https://spark.apache.org/docs/latest/api/sql/index.html#regexp] > Since this function has the same implementation as the Big Query > [REGEXP_CONTAINS|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_contains] > function. the implementation can be directly reused. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6261) RelBuilder.aggregate() field pruning does not use permuted field indices when used with force project and duplicate agg calls
[
https://issues.apache.org/jira/browse/CALCITE-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6261:
Labels: pull-request-available (was: )
> RelBuilder.aggregate() field pruning does not use permuted field indices when
> used with force project and duplicate agg calls
> -
>
> Key: CALCITE-6261
> URL: https://issues.apache.org/jira/browse/CALCITE-6261
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0, 1.36.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> We were running into issues with RelBuilder.aggregate() when we tried to
> upgrade our code from Calcite 1.32.0 to 1.36.0 and after some debugging it
> seems this is caused by changes introduced with CALCITE-4334.
> I was able to put together this test case for RelBuilderTest reproducing the
> issue:
> {code:java}
> @Test void testAggregateForceProject() {
> final Function f1 = builder ->
> builder.scan("EMP")
> .project(
> ImmutableList.of(
> builder.field("EMPNO"),
> builder.field("ENAME"),
> builder.field("JOB"),
> builder.field("MGR"),
> builder.field("HIREDATE"),
> builder.field("SAL"),
> builder.field("COMM"),
> builder.field("DEPTNO")),
> ImmutableList.of(),
> true);
> final Function f2 = builder ->
> builder.aggregate(
> builder.groupKey(builder.field("MGR")),
> builder.avg(false, "SALARY_AVG", builder.field("SAL")),
> builder.sum(false, "SALARY_SUM", builder.field("SAL")),
> builder.avg(false, "SALARY_MEAN", builder.field("SAL")));
> final String expected = ""
> + "LogicalProject(MGR=[$0], SALARY_AVG=[$1], SALARY_SUM=[$2],
> SALARY_MEAN=[$1])\n"
> + " LogicalAggregate(group=[{0}], SALARY_AVG=[AVG($1)],
> SALARY_SUM=[SUM($1)])\n"
> + "LogicalProject(MGR=[$3], SAL=[$5])\n"
> + " LogicalTableScan(table=[[scott, EMP]])\n";
> assertThat(f2.apply(f1.apply(createBuilder())).build(), hasTree(expected));
> } {code}
> With Calcite 1.36.0 you will get an AssertionError:
> {code:java}
> java.lang.AssertionError
> at org.apache.calcite.rel.core.Aggregate.(Aggregate.java:175)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.(LogicalAggregate.java:72)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create_(LogicalAggregate.java:144)
> at
> org.apache.calcite.rel.logical.LogicalAggregate.create(LogicalAggregate.java:116)
> at
> org.apache.calcite.rel.core.RelFactories$AggregateFactoryImpl.createAggregate(RelFactories.java:333)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2576)
> at org.apache.calcite.tools.RelBuilder.aggregate_(RelBuilder.java:2523)
> at org.apache.calcite.tools.RelBuilder.aggregate(RelBuilder.java:2335)
> at
> org.apache.calcite.test.RelBuilderTest.lambda$testAggregateForceProject$36(RelBuilderTest.java:1509)
> at
> org.apache.calcite.test.RelBuilderTest.testAggregateForceProject(RelBuilderTest.java:1522)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> 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
>
[jira] [Updated] (CALCITE-6275) Parser for data types ignores element nullability in collections
[
https://issues.apache.org/jira/browse/CALCITE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6275:
Labels: pull-request-available (was: )
> Parser for data types ignores element nullability in collections
>
>
> Key: CALCITE-6275
> URL: https://issues.apache.org/jira/browse/CALCITE-6275
> Project: Calcite
> Issue Type: Bug
> Components: core, server
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Major
> Labels: pull-request-available
>
> The parser (Parser.jj) has this production rule for DataType:
> {code}
> // Type name with optional scale and precision.
> SqlDataTypeSpec DataType() :
> {
> SqlTypeNameSpec typeName;
> final Span s;
> }
> {
> typeName = TypeName() {
> s = Span.of(typeName.getParserPos());
> }
> (
> typeName = CollectionsTypeName(typeName)
> )*
> {
> return new SqlDataTypeSpec(typeName,
> s.add(typeName.getParserPos()).pos());
> }
> }
> {code}
> Note that there is no way to specify the nullability for the elements of a
> collection, they are always assumed to be non-null. This is most pertinent
> for the server component, where in DDL one cannot specify a table column of
> type INTEGER ARRAY; one always gets an INTEGER NOT NULL ARRAY instead.
> But note that SqlCollectionTypeNameSpec cannot even represent the nullability
> of the elements' type, it takes a SqlTypeNameSpec instead of a
> SqlDataTypeSpec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6262) CURRENT_TIMESTAMP(P) ignores DataTypeSystem#getMaxPrecision
[
https://issues.apache.org/jira/browse/CALCITE-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6262:
Labels: pull-request-available (was: )
> CURRENT_TIMESTAMP(P) ignores DataTypeSystem#getMaxPrecision
> ---
>
> Key: CALCITE-6262
> URL: https://issues.apache.org/jira/browse/CALCITE-6262
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Adam Kennedy
>Priority: Major
> Labels: pull-request-available
>
> Datetime precision parameters are incorrectly validated against the DEFAULT
> maximum date time precision (3) instead of against the maximum date time
> precision configured by the DateTimeSystem#getMaxPrecision method.
> This breaks, at minimum, CURRENT_TIMESTAMP(P > 3) when precisions greater
> than 3 are supported by the system.
> The culprit is the following method in SqlAbstractTimeFunction
>
> {code:java}
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> // REVIEW jvs 20-Feb-2005: Need to take care of time zones.
> int precision = 0;
> if (opBinding.getOperandCount() == 1) {
> RelDataType type = opBinding.getOperandType(0);
> if (SqlTypeUtil.isNumeric(type)) {
> precision = getOperandLiteralValueOrThrow(opBinding, 0,
> Integer.class);
> }
> }
> assert precision >= 0;
> if (precision > SqlTypeName.MAX_DATETIME_PRECISION) {
> throw opBinding.newError(
> RESOURCE.argumentMustBeValidPrecision(
> opBinding.getOperator().getName(), 0,
> SqlTypeName.MAX_DATETIME_PRECISION));
> }
> return opBinding.getTypeFactory().createSqlType(typeName, precision);
> }{code}
>
>
> The correct value is readily accessible from
>
> {code:java}
> opBinding.getTypeFactory().getTypeSystem().getMaxPrecision(typeName){code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6274) Join Elasticsearch index return empty list
[
https://issues.apache.org/jira/browse/CALCITE-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6274:
Labels: pull-request-available (was: )
> Join Elasticsearch index return empty list
> --
>
> Key: CALCITE-6274
> URL: https://issues.apache.org/jira/browse/CALCITE-6274
> Project: Calcite
> Issue Type: Bug
> Environment: calcite 1.35.0
> elasticsearch 7.x
>Reporter: zhaowang
>Priority: Major
> Labels: pull-request-available
>
> Two index of Elasticsearch join return empty result even if the data from
> both indexes can match。
> create index test_01:
> {code:java}
> PUT /test_01/_doc/1
> {
> "doc_id" : 1,
> "doc_desc" : "doc01"
> } {code}
> create index test_02:
> {code:java}
> PUT /test_02/_doc/1
> {
> "doc_id" : 1,
> "doc_score" : 90
> } {code}
> execute sql:
> {code:java}
> select * from es.test_01 t1 join es.test_02 t2 on cast(t1._MAP['doc_id'] as
> bigint) = cast(t2._MAP['doc_id'] as bigint) {code}
> One row of result was expected, but actually get empty.
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6273) Add sqrt negative test in SqlOperatorTest
[ https://issues.apache.org/jira/browse/CALCITE-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6273: Labels: pull-request-available (was: ) > Add sqrt negative test in SqlOperatorTest > - > > Key: CALCITE-6273 > URL: https://issues.apache.org/jira/browse/CALCITE-6273 > Project: Calcite > Issue Type: Test > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Trivial > Labels: pull-request-available > Fix For: 1.37.0 > > > sqrt currently lacks some negatvie tests, such as sqrt(-1), sqrt(0), > sqrt(0.5), etc. The idea is mainly because of the log function -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6255) Support BigQuery-style JSON_OBJECT invocation syntax
[
https://issues.apache.org/jira/browse/CALCITE-6255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6255:
Labels: parser pull-request-available (was: parser)
> Support BigQuery-style JSON_OBJECT invocation syntax
>
>
> Key: CALCITE-6255
> URL: https://issues.apache.org/jira/browse/CALCITE-6255
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Barry Kelly
>Priority: Minor
> Labels: parser, pull-request-available
>
> Currently, Calcite has two styles for invoking JSON_OBJECT:
> {{ JSON_OBJECT(KEY 'foo' VALUE 'bar', KEY 'foo2' VALUE 'bar2')}}
> and:
> {{ JSON_OBJECT('foo' : 'bar', 'foo2' : 'bar')}}
> However,
> [BigQuery|https://cloud.google.com/bigquery/docs/reference/standard-sql/json_functions#json_object]
> uses a lighter-weight syntax resembling the MAP<> constructor, with an even
> numbered argument list where every odd item is a key and the following even
> item is a value:
> {{ JSON_OBJECT('foo', 'bar', 'foo2', 'bar2')}}
> With the objective of syntax compatibility with BigQuery, the simplest change
> to the grammar is to allow ',' as well as ':' for separating key/value pairs
> in the invocation.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6254) Enable calling table functions without requiring TABLE() wrapper
[
https://issues.apache.org/jira/browse/CALCITE-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6254:
Labels: parser pull-request-available (was: parser)
> Enable calling table functions without requiring TABLE() wrapper
>
>
> Key: CALCITE-6254
> URL: https://issues.apache.org/jira/browse/CALCITE-6254
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Barry Kelly
>Priority: Minor
> Labels: parser, pull-request-available
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Currently, when selecting from a table function, the function call needs to
> be wrapped in TABLE() like this:
> {{ SELECT * FROM TABLE(table_func('args'));}}
> Many dialects (SQL Server, PostgreSQL, BigQuery) do not require this:
> {{ SELECT * FROM table_func('args');}}
> The current Calcite grammar can be extended to permit this syntax without
> conflicting with other productions.
> There is a close call with the dynamic columns feature used by
> [Phoenix|https://phoenix.apache.org/dynamic_columns.html]
> {{ SELECT * FROM EventLog(lastGCTime TIME)}}
> It can be disambiguated with 3 tokens of lookahead, seeing past the '(' and
> identifier to the presence of a type production. The table extension clause
> for dynamic columns requires at least one field, so the empty case of '()' is
> not ambiguous either.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6268) Support implementing custom JdbcSchema
[
https://issues.apache.org/jira/browse/CALCITE-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6268:
Labels: pull-request-available (was: )
> Support implementing custom JdbcSchema
> --
>
> Key: CALCITE-6268
> URL: https://issues.apache.org/jira/browse/CALCITE-6268
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> Currently, it's not possible to implement a custom {{JdbcSchema}} because of
> the explicit type check in {{CalciteSchema::unwrap}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6267) Add subquery test、distinct test and cte test in ToLogicalConverterTest
[ https://issues.apache.org/jira/browse/CALCITE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6267: Labels: pull-request-available (was: ) > Add subquery test、distinct test and cte test in ToLogicalConverterTest > -- > > Key: CALCITE-6267 > URL: https://issues.apache.org/jira/browse/CALCITE-6267 > Project: Calcite > Issue Type: Wish > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Trivial > Labels: pull-request-available > > Consider adding subquery and ctetest to ToLogicalConverterTest. Although > there is nothing special about converting Logical and Physical, I think this > is added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6266) SqlValidatorException with LATERAL TABLE and JOIN
[
https://issues.apache.org/jira/browse/CALCITE-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6266:
Labels: pull-request-available (was: )
> SqlValidatorException with LATERAL TABLE and JOIN
> -
>
> Key: CALCITE-6266
> URL: https://issues.apache.org/jira/browse/CALCITE-6266
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.31.0, 1.32.0, 1.33.0, 1.34.0, 1.35.0, 1.36.0
>Reporter: Jeyhun Karimov
>Priority: Critical
> Labels: pull-request-available
>
> I have the following test in SqlValidatorTest.java
> {code:java}
> @Test void test() {
> sql("select * from dept, lateral table(ramp(deptno)) CROSS JOIN (VALUES
> ('A'), ('B'))")
> .ok();
> }
> {code}
> This test passes on Calcite {{calcite-1.29.0}} and {{calcite-1.30.0}} but
> fails on other releases, including the main branch
> (c774c313a81d01c4e3e77cf296d04839c5ab04c0). The exception is:
> {code:java}
> org.opentest4j.AssertionFailedError: Validator threw unexpected exception;
> query [select * from dept, lateral table(ramp(deptno)) CROSS JOIN (VALUES
> ('A'), ('B'))]; exception [Column 'DEPTNO' not found in any table]; class
> [class org.apache.calcite.sql.validate.SqlValidatorException]; pos [line 1
> col 40 thru line 1 col 40]
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38)
> at org.junit.jupiter.api.Assertions.fail(Assertions.java:135)
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:352)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:112)
> at
> org.apache.calcite.test.SqlValidatorFixture.ok(SqlValidatorFixture.java:191)
> at
> org.apache.calcite.test.SqlValidatorTest.jey2(SqlValidatorTest.java:284)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> 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.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> 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] [Updated] (CALCITE-6265) Cannot provide different numeric type as placeholder
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6265:
Labels: pull-request-available (was: )
> Cannot provide different numeric type as placeholder
>
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Tim Nieradzik
>Priority: Major
> Labels: pull-request-available
>
> The _empid_ column is of type {_}INT{_}. When providing a _short_ value as a
> placeholder, a _ClassCastException_ is thrown.
> *Test case:*
> {{ final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?,
> ?)";}}{{ CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> *Stack trace:*
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6157) SqlValidatorImpl breaks join condition when inlining table alias
[
https://issues.apache.org/jira/browse/CALCITE-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6157:
Labels: pull-request-available (was: )
> SqlValidatorImpl breaks join condition when inlining table alias
>
>
> Key: CALCITE-6157
> URL: https://issues.apache.org/jira/browse/CALCITE-6157
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> When switching from 1.35.0 to 1.36.0, {{SqlValidatorImpl}} breaks the join
> condition on the following statement
> {code:SQL}
> WITH `it1` AS (
> SELECT
> `company`,
> `area`,
> `revenue`,
> `regionId`
> FROM
> `12345678-1234-1234-1234-00010001`.`revenues`
> )
> SELECT
> *
> FROM
> (
> SELECT
> `T1`.`company` AS `company`,
> MAX(`T1`.`revenue`) AS `revenue`
> FROM
> `it1` AS `T1`
> GROUP BY
> `company`
> ) AS `T`
> LEFT JOIN `it1` AS `T2` ON `T`.`company` = `T2`.`company`
> AND `T`.`revenue` = `T2`.`revenue`
> {code}
> It modifies the join condition [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java#L3603-L3604]
> to
> {code:SQL}
> `T`.`company` = `T1`.`company`
> AND `T`.`revenue` = `T1`.`revenue`
> {code}
> which causes a "{{Table `T1`not found}}" exception.
> I already tried to reproduce the problem by adding the following test to
> {{SqlValidatorTest}}, but everything worked fine
> {code:java}
> @Test void testWith2() {
> sql("with it1 as (select empno, sal, deptno from emp)\n"
> + "select * from ( select t1.empno as empno, max(t1.deptno) as deptno
> from it1 as t1 group by empno) as t\n"
> + "left outer join it1 as t2 on t.empno = t2.empno and t.deptno =
> t2.deptno")
> .ok();
> }
> {code}
> During debugging, I recognized that the {{DelegatingScope}} does something
> different in our case [at this
> location|https://github.com/apache/calcite/blob/d3ab0bc8e4d4c9ebc0fc4e33ce478d276f5d11e4/core/src/main/java/org/apache/calcite/sql/validate/DelegatingScope.java#L333-L337].
> In our case the {{fromNs}} resolved to {{`it1` AS `T1`}}, which is wrong.
> But I was not able to find the root cause yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6260) Add already implemented functions in Spark library
[ https://issues.apache.org/jira/browse/CALCITE-6260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6260: Labels: pull-request-available (was: ) > Add already implemented functions in Spark library > -- > > Key: CALCITE-6260 > URL: https://issues.apache.org/jira/browse/CALCITE-6260 > Project: Calcite > Issue Type: Improvement >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > > Add Spark functions that have been implemented but have different > OperandTypes/Returns. > Spark Functions Link：[https://spark.apache.org/docs/latest/api/sql/index.html] > Add function List： > * CHR > * CONCAT_WS > * REGEXP > * REVERSE > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6258) Map value constructor is unparsed incorrectly for PrestoSqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6258:
Labels: pull-request-available (was: )
> Map value constructor is unparsed incorrectly for PrestoSqlDialect
> --
>
> Key: CALCITE-6258
> URL: https://issues.apache.org/jira/browse/CALCITE-6258
> Project: Calcite
> Issue Type: Bug
>Reporter: EveyWu
>Priority: Minor
> Labels: pull-request-available
>
> Presto Map function：{{{}map{}}}({_}array{_}, {_}array{_})
> https://teradata.github.io/presto/docs/current/functions/map.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6257) StarRocks dialect implementation
[ https://issues.apache.org/jira/browse/CALCITE-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6257: Labels: pull-request-available (was: ) > StarRocks dialect implementation > > > Key: CALCITE-6257 > URL: https://issues.apache.org/jira/browse/CALCITE-6257 > Project: Calcite > Issue Type: New Feature >Reporter: EveyWu >Priority: Minor > Labels: pull-request-available > > StarRocks has an MPP architecture and is equipped with a fully vectorized > execution engine, a columnar storage engine that supports real-time updates. > [https://docs.starrocks.io/docs/introduction/StarRocks_intro/] > At present, StarRocks has a wide range of applications. Implementing dialect > in Calcite will be valuable for many bi-services. > It closely follows MySQL but has enough differences to warrant a separate > dialect in Calcite. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6248:
Labels: pull-request-available (was: )
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6252) BigQuery FORMAT_DATE uses the wrong calendar for Julian dates
[
https://issues.apache.org/jira/browse/CALCITE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6252:
Labels: pull-request-available (was: )
> BigQuery FORMAT_DATE uses the wrong calendar for Julian dates
> -
>
> Key: CALCITE-6252
> URL: https://issues.apache.org/jira/browse/CALCITE-6252
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> For the following query:
> {code:sql}
> SELECT format_date('%A %d %B %Y', '0001-01-01')
> {code}
> the BigQuery playground returns the following result:
> {code}
> Monday 01 January 1
> {code}
> However, Calcite returns the following result:
> {code}
> Saturday 01 Jan 1
> {code}
> There are actually two bugs here:
> - the day of the week is wrong
> - the month name is displayed incorrectly. The latter is because of the
> Locale.ROOT used in SimpleDateFormat.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6247) BigQuery FORMAT_DATE function handles incorrectly the %e format specifier
[
https://issues.apache.org/jira/browse/CALCITE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6247:
Labels: pull-request-available (was: )
> BigQuery FORMAT_DATE function handles incorrectly the %e format specifier
> -
>
> Key: CALCITE-6247
> URL: https://issues.apache.org/jira/browse/CALCITE-6247
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Trivial
> Labels: pull-request-available
>
> According to the BigQuery spec
> https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements#format_elements_date_time
> the %e format specified should mean: "The day of month as a decimal number
> (1-31); single digits are preceded by a space."
> However, the implementation in FormatModels.java BIGQUERY is:
> {code:java}
> map.put("%e", DD);
> {code}
> which is the same as %d, which uses a leading 0 instead of a space.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6256) Incorrect rendering of HTML on InnoDB adapter page
[ https://issues.apache.org/jira/browse/CALCITE-6256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6256: Labels: pull-request-available (was: ) > Incorrect rendering of HTML on InnoDB adapter page > -- > > Key: CALCITE-6256 > URL: https://issues.apache.org/jira/browse/CALCITE-6256 > Project: Calcite > Issue Type: Bug > Components: site >Affects Versions: 1.36.0 >Reporter: Zhengqiang Duan >Assignee: Zhengqiang Duan >Priority: Major > Labels: pull-request-available > Attachments: image-2024-02-09-07-14-07-202.png > > > Hi, Calcite community, I found an error in rendering HTML on the [InnoDB > adapter page|[https://calcite.apache.org/docs/innodb_adapter.html].] > !image-2024-02-09-07-14-07-202.png|width=722,height=305! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-2980) Implement the FORMAT clause of the CAST operator
[
https://issues.apache.org/jira/browse/CALCITE-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-2980:
Labels: pull-request-available (was: )
> Implement the FORMAT clause of the CAST operator
>
>
> Key: CALCITE-2980
> URL: https://issues.apache.org/jira/browse/CALCITE-2980
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Jerin John
>Priority: Major
> Labels: pull-request-available
>
> SQL:2016 adds an optional {{FORMAT format}} clause to the {{CAST}} operator.
> It is a standard way to do what functions like {{TO_DATE}}, {{TO_NUMBER}},
> {{TO_CHAR}}, {{TO_TIMESTAMP}} have done in an ad hoc way (and with differing
> specifications among databases).
> Here is an example:
> {code:java}
> cast('01-05-2017' as date format 'DD-MM-')
> {code}
> The following paragraphs are copied from IMPALA-4018, which describes
> implementing this in Impala. (That case also describes cases where the
> implementations of {{TO_TIMESTAMP}} etc. in Hive, Impala, Oracle and
> PostgreSQL are not consistent with each other. We should take note as we
> implement these functions in Calcite.)
> SQL:2016 defines the following datetime templates
> {noformat}
> ::=
> { }...
> ::=
>
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> |
> ::=
> | YYY | YY | Y
> ::=
> | RR
> ::=
> MM
> ::=
> DD
> ::=
> DDD
> ::=
> HH | HH12
> ::=
> HH24
> ::=
> MI
> ::=
> SS
> ::=
> S
> ::=
> FF1 | FF2 | FF3 | FF4 | FF5 | FF6 | FF7 | FF8 | FF9
> ::=
> A.M. | P.M.
> ::=
> TZH
> ::=
> TZM
> {noformat}
> SQL:2016 also introduced the {{FORMAT}} clause for {{CAST}} which is the
> standard way to do string <> datetime conversions
> {noformat}
> ::=
> CAST
>AS
> [ FORMAT ]
>
> ::=
>
> |
> ::=
>
> |
> ::=
>
> {noformat}
> For example:
> {noformat}
> CAST( AS [FORMAT ])
> CAST( AS [FORMAT ])
> cast(dt as string format 'DD-MM-')
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6250) Improve MongoDB Documentation
[ https://issues.apache.org/jira/browse/CALCITE-6250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6250: Labels: pull-request-available (was: ) > Improve MongoDB Documentation > - > > Key: CALCITE-6250 > URL: https://issues.apache.org/jira/browse/CALCITE-6250 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Affects Versions: 1.35.0, 1.36.0 >Reporter: Corvin Kuebler >Assignee: Corvin Kuebler >Priority: Trivial > Labels: pull-request-available > > Enhance the documentation for the mongodb adapter with its current limitations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6251) innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed
[ https://issues.apache.org/jira/browse/CALCITE-6251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6251: Labels: pull-request-available (was: ) > innerEnumerator in EnumerableDefaults::correlateBatchJoin is not closed > --- > > Key: CALCITE-6251 > URL: https://issues.apache.org/jira/browse/CALCITE-6251 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.36.0 >Reporter: Ulrich Kramer >Priority: Major > Labels: pull-request-available > > The > [innerEnumerator|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1681] > is only closed at the end. But if there are multiple loops, [innerEnumerator > is just assigned to a different value without closing > it|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1720]. > It should look like > [here|https://github.com/apache/calcite/blob/f7069cc5245c22f816c565669f52b4f30b046f4d/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1547-L1550]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6249) RelNode::estimatedRowCount should not be used in computeSelfCost
[
https://issues.apache.org/jira/browse/CALCITE-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6249:
Labels: pull-request-available (was: )
> RelNode::estimatedRowCount should not be used in computeSelfCost
>
>
> Key: CALCITE-6249
> URL: https://issues.apache.org/jira/browse/CALCITE-6249
> Project: Calcite
> Issue Type: Bug
>Reporter: Ulrich Kramer
>Priority: Minor
> Labels: pull-request-available
>
> {{RelNode::estimatedRowCount}} is still used in many place inside
> {{computeSelfCost}}
> If it should be possible to implement the estimation of the row count
> completely outside Calcite, these calls should be replaced by
> {{mq.getRowCount(rel)}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6238) Exception while evaluating ROUND function
[
https://issues.apache.org/jira/browse/CALCITE-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6238:
Labels: pull-request-available (was: )
> Exception while evaluating ROUND function
> -
>
> Key: CALCITE-6238
> URL: https://issues.apache.org/jira/browse/CALCITE-6238
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following test in CalciteSqlOperatorTest:
> {code:java}
> @Test void testRoundFunc() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("round(42, CAST(2 as BIGINT))", 42, "INTEGER NOT NULL");
> }
> {code}
> causes an exception; here is the relevant part of the stack trace:
> {code}
> java.sql.SQLException: Error while executing SQL "values (round(42, CAST(2 as
> BIGINT)))": Unable to implement EnumerableCalc(expr#0=[{inputs}],
> expr#1=[42], expr#2=[2:BIGINT], expr#3=[ROUND($t1, $t2)], EXPR$0=[$t3]):
> rowcount = 1.0, cumulative cost = {2.0 rows, 6.0 cpu, 0.0 io}, id = 20
> EnumerableValues(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = {1.0
> rows, 1.0 cpu, 0.0 io}, id = 13
> ...
> Suppressed: java.lang.RuntimeException: while resolving method
> 'sround[int, long]' in class class org.apache.calcite.runtime.SqlFunctions
> at
> org.apache.calcite.adapter.enumerable.EnumUtils.call(EnumUtils.java:679)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.call(RexImpTable.java:2818)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$MethodImplementor.implementSafe(RexImpTable.java:2799)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.genValueStatement(RexImpTable.java:3857)
> at
> org.apache.calcite.adapter.enumerable.RexImpTable$AbstractRexCallImplementor.implement(RexImpTable.java:3819)
> {code}
> And indeed, SqlFunctions does not have a function sround with this signature.
> There are several possible fixes:
> - reject calls to ROUND that have a BIGINT second argument
> - have the validator insert an implicit cast for the second argument to
> INTEGER
> - implement more Java versions of the SROUND function in SqlFunctions.
> Probably many more.
> Which one of these is the right one? I suspect this problem applies to other
> SQL functions as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
