[jira] [Updated] (CALCITE-6584) Validate prefixed column identifiers in SET clause of UPDATE statement
[ https://issues.apache.org/jira/browse/CALCITE-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6584: Labels: pull-request-available (was: ) > Validate prefixed column identifiers in SET clause of UPDATE statement > -- > > Key: CALCITE-6584 > URL: https://issues.apache.org/jira/browse/CALCITE-6584 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Niels Pardon >Assignee: Niels Pardon >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > Add missing validator implementation for prefixed column identifiers in SET > clause of UPDATE statement as a follow-up to > [CALCITE-6576|https://issues.apache.org/jira/browse/CALCITE-6576] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6587) Support JDK 23 and Guava 33.3.0
[ https://issues.apache.org/jira/browse/CALCITE-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6587: Labels: pull-request-available (was: ) > Support JDK 23 and Guava 33.3.0 > --- > > Key: CALCITE-6587 > URL: https://issues.apache.org/jira/browse/CALCITE-6587 > Project: Calcite > Issue Type: Improvement >Reporter: Julian Hyde >Assignee: Julian Hyde >Priority: Major > Labels: pull-request-available > Fix For: 1.38.0 > > > Support JDK 23 and Guava 33.3.0-jre, which are the latest available versions. > The lower bound has not changed: we support JDK down to 8, and Guava down to > 21.0 (since CALCITE-5763). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6581) Incorrect INTERVAL math for WEEK and QUARTER
[
https://issues.apache.org/jira/browse/CALCITE-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6581:
Labels: pull-request-available (was: )
> Incorrect INTERVAL math for WEEK and QUARTER
>
>
> Key: CALCITE-6581
> URL: https://issues.apache.org/jira/browse/CALCITE-6581
> Project: Calcite
> Issue Type: Bug
>Reporter: Gian Merlino
>Priority: Major
> Labels: pull-request-available
>
> WEEK and QUARTER intervals are incorrectly translated to millis and months.
> {{'X' WEEK}} is treated like {{'X' HOUR}}, and {{'X' QUARTER}} is treated
> like {{'X' MONTH}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6580) Remove Locale.setDefault
[
https://issues.apache.org/jira/browse/CALCITE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6580:
Labels: pull-request-available (was: )
> Remove Locale.setDefault
>
>
> Key: CALCITE-6580
> URL: https://issues.apache.org/jira/browse/CALCITE-6580
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
>
> Remove all calls to {{Locale.setDefault}} in tests and production code.
> That function does not operate on the current thread; it affects all threads
> in the JVM. As such, it may affect other tests running at the same time, and
> affect other statements running at the same time.
> I hope, and believe, that the production code does not depend on
> {{Locale.getDefault}}. But let's make sure by removing {{setDefault}} from
> all tests.
> Add {{Locale.setDefault}} to
> [forbidden-apis|https://github.com/apache/calcite/blob/main/src/main/config/forbidden-apis/signatures.txt].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6570) Assertion error when validating an UPDATE query with a subquery expression
[
https://issues.apache.org/jira/browse/CALCITE-6570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6570:
Labels: pull-request-available (was: )
> Assertion error when validating an UPDATE query with a subquery expression
> --
>
> Key: CALCITE-6570
> URL: https://issues.apache.org/jira/browse/CALCITE-6570
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: pull-request-available
>
> Reproducer (for SqlToRelConverterTest)
> {code:java}
> @Test void testUpdateSubQuery() {
> final String sql = "update emp\n"
> + "set empno = (\n"
> + " select cast(empno as BIGINT) from emp" +
> ")";
> sql(sql).ok();
> }
> {code}
> Produces the following assertion error
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:307)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:250)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.coerceColumnType(AbstractTypeCoercion.java:210)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.coerceSourceRowType(TypeCoercionImpl.java:676)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.querySourceCoercion(TypeCoercionImpl.java:646)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.checkTypeAssignment(SqlValidatorImpl.java:5313)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateUpdate(SqlValidatorImpl.java:5420)
> at org.apache.calcite.sql.SqlUpdate.validate(SqlUpdate.java:190)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1136)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:841)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.convertSqlToRel2(AbstractSqlTester.java:543)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertSqlConvertsTo(AbstractSqlTester.java:486)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertConvertsTo(AbstractSqlTester.java:464)
> at
> org.apache.calcite.test.SqlToRelFixture.convertsTo(SqlToRelFixture.java:106)
> at org.apache.calcite.test.SqlToRelFixture.ok(SqlToRelFixture.java:94)
> at
> org.apache.calcite.test.SqlToRelConverterTest.testUpdateSubQuery(SqlToRelConverterTest.java:3077)
> {noformat}
> The same query without casting to BIGINT works fine.
> Assertion line
> {code:java}
> // Should keep sync with rules in SqlTypeCoercionRule.
> assert SqlTypeUtil.canCastFrom(toType, fromType, mappingRule);
> return true;
> {code}
> When assertion fails, I see that
> toType = INTEGER
> fromType = RecordType(BIGINT EXPR$0)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6529) Use persistent sessionContext in AvaticaCommonsHttpClientImpl
[ https://issues.apache.org/jira/browse/CALCITE-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6529: Labels: pull-request-available (was: ) > Use persistent sessionContext in AvaticaCommonsHttpClientImpl > - > > Key: CALCITE-6529 > URL: https://issues.apache.org/jira/browse/CALCITE-6529 > Project: Calcite > Issue Type: Improvement >Reporter: Istvan Toth >Priority: Minor > Labels: pull-request-available > > We are re-creating and setting up a SessionContext object for each HTTP call. > We could use a sessionContext method for the same purpose, or even better, > just set those properties directly on the HttpClient object. > Every member of HttpSession is duplicated in HttpClient, HttpSession is only > used as an override. Since we have a 1:1 relationship between HttpClient and > HttpSession objects, HttpSession is redundant. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6374) LatticeSuggester throw NullPointerException when agg call covered with cast
[
https://issues.apache.org/jira/browse/CALCITE-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6374:
Labels: pull-request-available (was: )
> LatticeSuggester throw NullPointerException when agg call covered with cast
>
>
> Key: CALCITE-6374
> URL: https://issues.apache.org/jira/browse/CALCITE-6374
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: allendang
>Priority: Critical
> Labels: pull-request-available
>
> I changed {color:#de350b}q1{color} in
> {color:#4c9aff}org.apache.calcite.materialize.LatticeSuggesterTest#testExpressionEvolution{color}
> It was originally like this
> {code:java}
> select
> "num_children_at_home" + 10 as "n10",
> "num_children_at_home" + 14 as "n14",
> sum("num_children_at_home" + 12) as "n12",
> sum("num_children_at_home" + 13) as "n13"
> from "customer"
> group by "num_children_at_home" + 10, "num_children_at_home" + 14 {code}
> i changed it like following
> {code:java}
> select
> "num_children_at_home" + 10 as "n10",
> "num_children_at_home" + 14 as "n14",
> cast(sum("num_children_at_home" + 12) as double) as "n12",
> sum("num_children_at_home" + 13) as "n13"
> from "customer"
> group by "num_children_at_home" + 10, "num_children_at_home" + 14 {code}
> Re-running the test case throws the following exception
> {code:java}
> measure.name
> java.lang.NullPointerException: measure.name
> at java.util.Objects.requireNonNull(Objects.java:228)
> at
> org.apache.calcite.materialize.LatticeSuggester.deriveAlias(LatticeSuggester.java:290)
> at
> org.apache.calcite.materialize.LatticeSuggester.lambda$addFrame$3(LatticeSuggester.java:250)
> at org.apache.calcite.util.Util$TransformingList.get(Util.java:2810)
> at java.util.AbstractList$Itr.next(AbstractList.java:358)
> at java.util.AbstractCollection.toArray(AbstractCollection.java:141)
> at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:265)
> at com.google.common.collect.ImmutableList.copyOf(ImmutableList.java:238)
> at org.apache.calcite.materialize.Lattice$Measure.(Lattice.java:567)
> at
> org.apache.calcite.materialize.LatticeSuggester.addFrame(LatticeSuggester.java:240)
>
> at
> org.apache.calcite.materialize.LatticeSuggester.lambda$addQuery$1(LatticeSuggester.java:143)
> at java.util.ArrayList.forEach(ArrayList.java:1259)
> at
> org.apache.calcite.materialize.LatticeSuggester.addQuery(LatticeSuggester.java:143)
> at
> org.apache.calcite.materialize.LatticeSuggesterTest$Tester.addQuery(LatticeSuggesterTest.java:851)
> at
> org.apache.calcite.materialize.LatticeSuggesterTest.testExpressionEvolution(LatticeSuggesterTest.java:551){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6572) Add more tests for NULL result of TO_CHAR PostgreSQL function
[ https://issues.apache.org/jira/browse/CALCITE-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6572: Labels: pull-request-available (was: ) > Add more tests for NULL result of TO_CHAR PostgreSQL function > - > > Key: CALCITE-6572 > URL: https://issues.apache.org/jira/browse/CALCITE-6572 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Claude Brisson >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > We would expect the result of TO_CHAR(, ) to be > nullable, while it is not for now. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6576) SqlParser does not support using UPDATE table alias with column identifiers in SET
[
https://issues.apache.org/jira/browse/CALCITE-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6576:
Labels: pull-request-available (was: )
> SqlParser does not support using UPDATE table alias with column identifiers
> in SET
> --
>
> Key: CALCITE-6576
> URL: https://issues.apache.org/jira/browse/CALCITE-6576
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Niels Pardon
>Assignee: Niels Pardon
>Priority: Minor
> Labels: pull-request-available
>
> The Apache Calcite SQL parser does allow to assign a table alias within an
> UPDATE statement but the table alias can currently not be used with the
> column identifiers within the SET section.
> The following can be parsed successfully:
> {code:sql}
> UPDATE mytable AS t SET ID=1;
> UPDATE mytable t SET ID=1;
> {code}
> But the parser fails as soon as the table alias is used with the column
> identifier in the SET section:
> {code:sql}
> UPDATE mytable AS t SET t.ID=1;
> UPDATE mytable t SET t.ID=1;
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6569) RelToSqlConverter support IGNORE NULLS for window functions
[
https://issues.apache.org/jira/browse/CALCITE-6569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6569:
Labels: pull-request-available (was: )
> RelToSqlConverter support IGNORE NULLS for window functions
> ---
>
> Key: CALCITE-6569
> URL: https://issues.apache.org/jira/browse/CALCITE-6569
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Jiajun Xie
>Assignee: Jiajun Xie
>Priority: Major
> Labels: pull-request-available
>
> CALCITE-883(https://issues.apache.org/jira/browse/CALCITE-883) Support
> IGNORE NULLS option for LEAD, LAG, FIRST_VALUE, LAST_VALUE and NTH_VALUE
> window functions.
> But RelToSqlConverter not support them, IGNORE NULLS will be lost.
>
> For example
>
> {code:java}
> SELECT LAG("employee_id", 2) IGNORE NULLS OVER (ORDER BY "hire_date")
> FROM "employee"{code}
>
> It lost `IGNORE NULLS `
> {code:java}
> SELECT LAG("employee_id", 2) OVER (ORDER BY "hire_date")
> FROM "employee"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6566) JDBC adapter should generate PI function with parentheses When unparse PI function without parentheses
[
https://issues.apache.org/jira/browse/CALCITE-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6566:
Labels: pull-request-available (was: )
> JDBC adapter should generate PI function with parentheses When unparse PI
> function without parentheses
> --
>
> Key: CALCITE-6566
> URL: https://issues.apache.org/jira/browse/CALCITE-6566
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Now In Calcite, support the PI function:
> {code:java}
> select PI;
> return 3.141592653589793
> {code}
> Jdbc will generate:
> {code:java}
> SELECT PI AS "PI" FROM (VALUES (0)) AS "t" ("ZERO");{code}
> However, they always need parentheses when I test in different data sources.
> Spark:
> {code:java}
> select PI();
> return 3.141592653589793
> select PI;
> Error in query: cannot resolve '`PI`' given input columns: []; line 1 pos
> 7;{code}
> Hive:
> {code:java}
> select PI();
> return 3.141592653589793
> select PI;
> SemanticException [Error 10004]: Line 1:7 Invalid table alias or column
> reference 'PI': (possible column names are: ) (state=42000,code=10004){code}
> Postgresql:
> {code:java}
> select PI();
> return 3.141592653589793
> select PI;
> ERROR: column "pi" does not exist{code}
> MySQL:
> {code:java}
> select PI();
> return 3.141593
> select PI;
> ERROR 1054 (42S22) at line 1: Unknown column 'PI' in 'field list'{code}
> SQLServer:
> {code:java}
> select PI();
> 3.1415926535897931
> select PI;{code}
> So I will generate PI() in Jdbc Dialect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6413) SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for both NATURAL and USING join conditions
[
https://issues.apache.org/jira/browse/CALCITE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6413:
Labels: pull-request-available (was: )
> SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for
> both NATURAL and USING join conditions
> ---
>
> Key: CALCITE-6413
> URL: https://issues.apache.org/jira/browse/CALCITE-6413
> Project: Calcite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: pull-request-available
>
> This can be observed by adding these test cases to `SqlToRelConverterTest`:
> 1. Join condition ON expression
> {code:java}
> @Test void test1() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno) ON
> emp.deptno = t.deptno";
> sql(sql).ok();
> }
> {code}
> 2. Common columns (USING/NATURAL) (since they both share the same code path
> for building join condition)
> {code:java}
> @Test void test2() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno)
> USING (deptno)";
> sql(sql).ok();
> }
> {code}
> When test 1 runs, the SqlValidator calls
> TypeCoercionImpl::binaryComparisonCoercion
> When test 2 runs, the SqlValidator does not call
> TypeCoercionImpl::binaryComparisonCoercion.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6563) RelToSqlConverter should not merge two window functions
[
https://issues.apache.org/jira/browse/CALCITE-6563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6563:
Labels: pull-request-available (was: )
> RelToSqlConverter should not merge two window functions
> ---
>
> Key: CALCITE-6563
> URL: https://issues.apache.org/jira/browse/CALCITE-6563
> Project: Calcite
> Issue Type: Bug
>Reporter: suibianwanwan
>Assignee: suibianwanwan
>Priority: Critical
> Labels: pull-request-available
>
> For example, test in RelToSqlConverterTest:
> {code:java}
> @Test void testNestWindow() {
> String query = " SELECT RANK() OVER (ORDER BY \"daily_sales\" DESC) AS
> \"rank1\" "
> + "FROM ( SELECT \"product_name\", "
> + "SUM(\"product_id\") OVER (PARTITION BY \"product_name\") AS
> \"daily_sales\" "
> + "FROM \"product\" ) subquery";
> String expected0 = "SELECT RANK() OVER (ORDER BY 2 DESC) AS \"$0\"\n"
> + "FROM \"foodmart\".\"product\"";
> RuleSet rules =
> RuleSets.ofList(CoreRules.PROJECT_TO_LOGICAL_PROJECT_AND_WINDOW);
> sql(query).optimize(rules, null) .ok(expected0);
> }
> {code}
> Plan:
> {code:java}
> LogicalWindow(window#0=[window(order by [1 DESC] aggs [RANK()])])
> LogicalProject(product_name=[$3], $1=[$15])
> LogicalWindow(window#0=[window(partition {3} aggs [SUM($1)])])
> JdbcTableScan(table=[[foodmart, product]])
> {code}
> The first window is not correctly converted to SQL
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4918) Add a VARIANT data type
[ https://issues.apache.org/jira/browse/CALCITE-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-4918: Labels: pull-request-available (was: ) > Add a VARIANT data type > --- > > Key: CALCITE-4918 > URL: https://issues.apache.org/jira/browse/CALCITE-4918 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Assignee: Mihai Budiu >Priority: Major > Labels: pull-request-available > > Add a VARIANT data type. It would be a tagged union, and allow values of > multiple types to be stored, along with a type indicator so that the actual > type of each value can be discerned. > VARIANT is not in the SQL standard. I know of three databases that have a > VARIANT type: MSSQL, Snowflake, Teradata. Calcite's VARIANT type will > probably draw from all three; however, the goal is not full compliance with > any of them, but useful functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6561) incorrect value calculated for AS MEASURE aggregate when grouping by a column with NULLs
[
https://issues.apache.org/jira/browse/CALCITE-6561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6561:
Labels: pull-request-available (was: )
> incorrect value calculated for AS MEASURE aggregate when grouping by a column
> with NULLs
>
>
> Key: CALCITE-6561
> URL: https://issues.apache.org/jira/browse/CALCITE-6561
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Adam Markowitz
>Priority: Minor
> Labels: pull-request-available
>
> Test case using an `AS MEASURE` aggregate with expected data:
>
> {code:java}
> !set outputformat mysql
> !use scott
> create view empm as
> select *, avg(sal) as measure avg_sal
> from emp;
> (0 rows modified)
> !update
> # GROUP BY a dimension with NULLs
> SELECT mgr, avg_sal FROM empm
> GROUP BY mgr;
> +--+-+
> | MGR | AVG_SAL |
> +--+-+
> | 7566 | 3000.00 |
> | 7698 | 1310.00 |
> | 7782 | 1300.00 |
> | 7788 | 1100.00 |
> | 7839 | 2758.33 |
> | 7902 | 800.00 |
> | | 5000.00 |
> +--+-+
> (7 rows)
> !ok
> {code}
> The NULL value does not get the aggregate value causing a failure:
> {code:java}
> < | | 5000.00 |
> ---
> > | | | {code}
> However, swapping out the `AS MEASURE` column reference with an inline
> aggregate results in the correct data:
> {code:java}
> SELECT mgr, avg(sal) as avg_sal FROM empm
> GROUP BY mgr;
> +--+-+
> | MGR | AVG_SAL |
> +--+-+
> | 7566 | 3000.00 |
> | 7698 | 1310.00 |
> | 7782 | 1300.00 |
> | 7788 | 1100.00 |
> | 7839 | 2758.33 |
> | 7902 | 800.00 |
> | | 5000.00 |
> +--+-+
> (7 rows)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6560) Add supportsNegativeScale in RelDataTypeSystem
[ https://issues.apache.org/jira/browse/CALCITE-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6560: Labels: pull-request-available (was: ) > Add supportsNegativeScale in RelDataTypeSystem > --- > > Key: CALCITE-6560 > URL: https://issues.apache.org/jira/browse/CALCITE-6560 > Project: Calcite > Issue Type: Improvement >Reporter: xiong duan >Priority: Major > Labels: pull-request-available > > [https://www.postgresql.org/docs/current/datatype-numeric.html] > According to the document, a numeric column with a negative scale can be > declared beginning in PostgreSQL 15. This PR will add some tests to cover > supportsNegativeScale is false and will throw an exception if set > supportsNegativeScale is true. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5613) Add assert for number of args for metadata methods at CacheGeneratorUtil
[
https://issues.apache.org/jira/browse/CALCITE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5613:
Labels: pull-request-available (was: )
> Add assert for number of args for metadata methods at CacheGeneratorUtil
>
>
> Key: CALCITE-5613
> URL: https://issues.apache.org/jira/browse/CALCITE-5613
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0
>Reporter: Sergey Nuyanzin
>Priority: Trivial
> Labels: pull-request-available
>
> The problem is that it implicitly implies that method should have 2+ args
> based on
> {{org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil.CacheKeyStrategy#safeArgList}}.
> At the same time different libs like JaCoCo could generate extra methods like
> {{private static boolean[]
> org.apache.calcite.rel.metadata.BuiltInMetadata$Predicates$Handler.$jacocoInit()}}.
> It took several hours to realize it since currently it complains like
> {noformat}
> java.lang.IllegalArgumentException: fromIndex(2) > toIndex(0)
> at
> java.base/java.util.AbstractList.subListRangeCheck(AbstractList.java:509)
> at java.base/java.util.AbstractList.subList(AbstractList.java:497)
> at
> org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil$CacheKeyStrategy$1.safeArgList(CacheGeneratorUtil.java:213)
> at
> org.apache.calcite.rel.metadata.janino.CacheGeneratorUtil$CacheKeyStrategy$1.cacheKeyBlock(CacheGeneratorUtil.java:205)
> ...
> {noformat}
> The idea is to put assert something like that
> {code:java}
> assert method.getParameterCount() >= 2 : method.toString();
> {code}
> to simplify the process of finding the root cause
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6516) AVG to SUM+COUNT transformation inserts invalid CAST call
[
https://issues.apache.org/jira/browse/CALCITE-6516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6516:
Labels: pull-request-available (was: )
> AVG to SUM+COUNT transformation inserts invalid CAST call
> -
>
> Key: CALCITE-6516
> URL: https://issues.apache.org/jira/browse/CALCITE-6516
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.37.0
>Reporter: Leonid Chistov
>Priority: Major
> Labels: pull-request-available
>
> As described in https://issues.apache.org/jira/browse/CALCITE-4911.
> In Calcite:
> {code:java}
> select avg(comm) as a from "scott".emp{code}
> This SQL physical plan is:
> {noformat}
> EnumerableCalc(expr#0..1=[{inputs}], expr#2=[0], expr#3=[=($t1, $t2)],
> expr#4=[null:DECIMAL(19, 2)], expr#5=[CASE($t3, $t4, $t0)],
> expr#6=[CAST($t5):DECIMAL(7, 2)], expr#7=[/($t6, $t1)],
> expr#8=[CAST($t7):DECIMAL(7, 2)], A=[$t8])
> EnumerableAggregate(group=[{}], agg#0=[$SUM0($6)], agg#1=[COUNT($6)])
> EnumerableTableScan(table=[[scott, EMP]]){noformat}
> Problem here is that cast of SUM result to DECIMAL(7, 2) is not correct and
> may cause overflow error at runtime or result in not expected data truncation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6554) nested correlated sub-query in aggregation does not have inner correlation variable bound to inner projection
[
https://issues.apache.org/jira/browse/CALCITE-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6554:
Labels: pull-request-available (was: )
> nested correlated sub-query in aggregation does not have inner correlation
> variable bound to inner projection
> -
>
> Key: CALCITE-6554
> URL: https://issues.apache.org/jira/browse/CALCITE-6554
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.37.0
>Reporter: Ian Bertolacci
>Assignee: Ian Bertolacci
>Priority: Major
> Labels: pull-request-available
>
> It appears that nested correlated subqueries can (at least in aggregates)
> result in project nodes not having their variablesSet populated with the
> correct (or any) correlation variables.
> For example:
> {code:java}
> @Test void testCorrelationInProjectionWith1xNestedCorrelatedProjection() {
> final String sql =
> "select e1.empno,\n"
> + " (select sum(e2.sal +\n"
> + "(select sum(e3.sal) from emp e3 where e3.mgr = e2.empno)\n"
> + " ) from emp e2 where e2.mgr = e1.empno)\n"
> + "from emp e1";
> sql(sql).withExpand(false).withDecorrelate(false).ok();
> }
> {code}
> currently gives the following plan:
> {code:java}
> LogicalProject(variablesSet=[[$cor0]], EMPNO=[$0], EXPR$1=[$SCALAR_QUERY({
> LogicalAggregate(group=[{}], EXPR$0=[SUM($0)])
> LogicalProject($f0=[+($5, $SCALAR_QUERY({
> LogicalAggregate(group=[{}], EXPR$0=[SUM($0)])
> LogicalProject(SAL=[$5])
> LogicalFilter(condition=[=($3, $cor1.EMPNO)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> }))])
> LogicalFilter(condition=[=($3, $cor0.EMPNO)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> })])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> Notice that cor1 is not bound to the inner query's projection nodes
> variablesSet as cor0 is to the outer query's projection node.
> This results in improper subquery removal (which was originally believed to
> be an issue with the rule itself, discussed in CALCITE-5213)
> This is because in [SqlToRelConverter.createAggImpl, it does not check for
> correlation variables after creating an intermediate
> project|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L3589-L3595]
> in the same way that
> [SqlToRelConverter.convertSelectList|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L4754-L4766]
> does.
> This patch fixes addresses this issue:
> {code:none}
> diff --git
> a/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java
> b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java
> index d88daa631..5668bc825 100644
> --- a/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java
> +++ b/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java
> @@ -3587,11 +3587,26 @@ private void createAggImpl(Blackboard bb,
>final RelNode inputRel = bb.root();
>// Project the expressions required by agg and having.
> - bb.setRoot(
> - relBuilder.push(inputRel)
> - .projectNamed(preExprs.leftList(), preExprs.rightList(), false)
> - .build(),
> - false);
> + {
> +RelNode intermediateProject = relBuilder.push(inputRel)
> +.projectNamed(preExprs.leftList(), preExprs.rightList(), false)
> +.build();
> +final RelNode r2;
> +// deal with correlation
> +final CorrelationUse p = getCorrelationUse(bb, intermediateProject);
> +if (p != null) {
> + assert p.r instanceof Project;
> + // correlation variables have been normalized in p.r, we should
> use expressions
> + // in p.r instead of the original exprs
> + Project project1 = (Project) p.r;
> + r2 = relBuilder.push(bb.root())
> + .projectNamed(project1.getProjects(),
> project1.getRowType().getFieldNames(), true, ImmutableSet.of(p.id))
> + .build();
> +} else {
> + r2 = intermediateProject;
> +}
> +bb.setRoot(r2, false);
> + }
>bb.mapRootRelToFieldProjection.put(bb.root(), r.groupExprProjection);
>// REVIEW jvs 31-Oct-2007: doesn't the declaration of
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6552) Enable CheckerFramework in 'server' module
[
https://issues.apache.org/jira/browse/CALCITE-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6552:
Labels: pull-request-available (was: )
> Enable CheckerFramework in 'server' module
> --
>
> Key: CALCITE-6552
> URL: https://issues.apache.org/jira/browse/CALCITE-6552
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
>
> In CALCITE-4199 we enabled CheckerFramework (via annotations and CI jobs) in
> the 'core' and 'linq4j' modules; this change further enables CheckerFramework
> in the 'server' module, and fixes all violations.
> There are also a large number of 'cosmetic' modifications to improve code
> quality without changing behavior, including:
> * Replace '{{this.x = x; assert x != null;}}' by '{{this.x =
> requireNonNull\(x);}}' in constructors
> * Replace {{assert}} in other code locations where it implements an
> invariant. We don't use {{requireNonNull}} because it throws
> {{NullPointerException}}; we would prefer to throw {{AssertionError}} or
> {{IllegalStateException}}
> * Replace {{x.equals("")}} and {{x.size() == 0}} with {{x.isEmpty()}}
> * Make fields {{final}} where possible
> * Make private methods and inner classes {{static}} where possible
> * In {{class Pair}} make the type variables {{K}} and {{V}} no longer
> {{@Nullable}} by default (you can make each of them nullable if you need)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6551) Add DATE_FORMAT function (enabled in MySQL library)
[ https://issues.apache.org/jira/browse/CALCITE-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6551: Labels: pull-request-available (was: ) > Add DATE_FORMAT function (enabled in MySQL library) > --- > > Key: CALCITE-6551 > URL: https://issues.apache.org/jira/browse/CALCITE-6551 > Project: Calcite > Issue Type: New Feature >Reporter: suibianwanwan >Assignee: suibianwanwan >Priority: Minor > Labels: pull-request-available > > Similar to the to_date function in > PostgreSQL > Document: > https://dev.mysql.com/doc/refman/8.4/en/date-and-time-functions.html#function_date-format -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6548) Result type inferred for COVAR_SAMP、COVAR_POP is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6548: Labels: pull-request-available (was: ) > Result type inferred for COVAR_SAMP、COVAR_POP is incorrect > -- > > Key: CALCITE-6548 > URL: https://issues.apache.org/jira/browse/CALCITE-6548 > Project: Calcite > Issue Type: Improvement >Reporter: xiong duan >Assignee: xiong duan >Priority: Major > Labels: pull-request-available > > COVAR_SAMP can return NULL. If the function is applied to an empty set, it > returns null. E.g. see the Oracle documentation: > [https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/VAR_SAMP.html|https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/COVAR_SAMP.html] > . > COVAR_POP see the Oracle documentation: > [https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/COVAR_POP.html|https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/COVAR_POP.html]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6549) Add LOG1P function (enabled in Spark library)
[ https://issues.apache.org/jira/browse/CALCITE-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6549: Labels: pull-request-available (was: ) > Add LOG1P function (enabled in Spark library) > - > > Key: CALCITE-6549 > URL: https://issues.apache.org/jira/browse/CALCITE-6549 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > Fix For: 1.38.0 > > > Returns log(1 + `expr`). > https://spark.apache.org/docs/3.4.0/sql-ref-functions-builtin.html#mathematical-functions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6547) Result type inferred for STDDEV_SAMP is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6547: Labels: pull-request-available (was: ) > Result type inferred for STDDEV_SAMP is incorrect > - > > Key: CALCITE-6547 > URL: https://issues.apache.org/jira/browse/CALCITE-6547 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > STDDEV_SAMP can return NULL even if the input is non-null and non-empty - it > returns NULL when the input set has only one element. E.g. see the Oracle > documentation: > https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/VAR_SAMP.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6546) Hive dialect does not support a sub-query in the FROM clause without alias
[
https://issues.apache.org/jira/browse/CALCITE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6546:
Labels: pull-request-available (was: )
> Hive dialect does not support a sub-query in the FROM clause without alias
> --
>
> Key: CALCITE-6546
> URL: https://issues.apache.org/jira/browse/CALCITE-6546
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> In Hive, the SQL:
> {code:java}
> select * from (select * from table1);
> {code}
> will throw an exception:
> {code:java}
> Error: Error while compiling statement: FAILED: ParseException line 1:36
> cannot recognize input near '' '' '' in subquery source
> (state=42000,code=4)
> {code}
> The SQL：
> {code:java}
> select * from (select * from table1) as table2;
> {code}
> works well.
> So when we generate the Hive SQL in the Jdbc adapter, we need to create an
> alias for the sub-query in the From clause.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4806) Lossy CAST is incorrectly simplified
[
https://issues.apache.org/jira/browse/CALCITE-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4806:
Labels: pull-request-available (was: )
> Lossy CAST is incorrectly simplified
>
>
> Key: CALCITE-4806
> URL: https://issues.apache.org/jira/browse/CALCITE-4806
> Project: Calcite
> Issue Type: Bug
>Reporter: xuyang
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> the sql is following:
> {code:java}
> // code placeholder
> select cast(1.1 as int) = cast (1 as int){code}
> In SQLite the result is 1 and in postgreSQL the result is true.
> But in calcite the result is false.
> The bug is in RexSimplify and 1.1 and 1 are all converted to
> java.lang.Comparable, and 1.1 doesn't equal to 1. It ignores the source data
> type. The literal 1.1 should be cast to 1(int) first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6543) Change the RelOptCostImpl toString method to be consistent with VolcanoCost
[
https://issues.apache.org/jira/browse/CALCITE-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6543:
Labels: pull-request-available (was: )
> Change the RelOptCostImpl toString method to be consistent with VolcanoCost
> ---
>
> Key: CALCITE-6543
> URL: https://issues.apache.org/jira/browse/CALCITE-6543
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Jie Cheng
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Hello everyone, I am a calcite novice, recently learning calcite source code,
> in the process of learning, found that RelOptCostImpl toString method is
> inconsistent with the VolcanoCost method, I think we should revise them to be
> similar
> before modification：
> @Override public String toString() {
> if (value == Double.MAX_VALUE) {
> return "huge";
> } else {
> return Double.toString(value);
> }
> }
> after modification：
> @Override public String toString() {
> if (value == Double.MAX_VALUE) {
> return "huge";
> } else if (value == Double.POSITIVE_INFINITY) {
> return "inf";
> } else if (value == 1.0) {
> return "tiny";
> } else if (value == 0.0) {
> return "0";
> } else {
> return Double.toString(value);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5883) Calcite ignores ROWS window frames when there is no ORDER BY clause
[
https://issues.apache.org/jira/browse/CALCITE-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5883:
Labels: pull-request-available (was: )
> Calcite ignores ROWS window frames when there is no ORDER BY clause
> ---
>
> Key: CALCITE-5883
> URL: https://issues.apache.org/jira/browse/CALCITE-5883
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Itiel Sadeh
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When specifying window frame without an ORDER BY clause, Calcite will ignore
> it and will generate the frame UNBOUNDED PRECEDING to UNBOUNDED FOLLOWING.
> e.g, calcite will translate
> {code:java}
> SELECT sum(x) over(partition by y ROWS between CURRENT ROW and UNBOUNDED
> FOLLOWING) from t
> {code}
> into
> {code:java}
> SELECT sum(x) over(partition by y RANGE between UNBOUNDED FOLLOWING and
> UNBOUNDED FOLLOWING) from t
> {code}
> There is a comment in the offending code (SqlToRelConverter.java:2207) which
> states that
> ??"without ORDER BY, there must be no bracketing"?? . I've tried to find a
> specification like that in the SQL 2003 standard, but didn't find anything to
> that effect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6540) RelOptUtil.pushDownJoinConditions does not correctly adjust ASOF joins match conditions
[ https://issues.apache.org/jira/browse/CALCITE-6540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6540: Labels: pull-request-available (was: ) > RelOptUtil.pushDownJoinConditions does not correctly adjust ASOF joins match > conditions > --- > > Key: CALCITE-6540 > URL: https://issues.apache.org/jira/browse/CALCITE-6540 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.38.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > ASOF join was introduced recently by CALCITE-6372 > The implementation parallels the join implementation. However, the function > RelOptUtil.pushDownJoinConditions may adjust the join condition. When that > happens, the asof matchCondition may need to be adjusted too. This last > adjustment is missing, which can cause the matchCondition to be wrong, > because the offsets of the RexInputRef fields are not appropriately adjusted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6346) JdbcAdapter: Cast for dynamic filter arguments is lost
[
https://issues.apache.org/jira/browse/CALCITE-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6346:
Labels: pull-request-available (was: )
> JdbcAdapter: Cast for dynamic filter arguments is lost
> --
>
> Key: CALCITE-6346
> URL: https://issues.apache.org/jira/browse/CALCITE-6346
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.36.0
>Reporter: Corvin Kuebler
>Priority: Major
> Labels: pull-request-available
>
> Hey,
> today we encouraged some issues with the jdbc adapter behaviour.
> We have a statement like this:
> {code:java}
> SELECT CASE WHEN CAST(? AS VARCHAR) = CAST(? AS VARCHAR) THEN "NAME" END
> FROM "AUTHORS"
> The parameters are ["some", 1].
> {code}
> The statement that is pushed via JDBC Adapter looks like this:
> {code:java}
> SELECT CASE WHEN ? = ? THEN "NAME" END
> FROM "AUTHORS"
> {code}
> The cast in the resulting statement is lost and therefore we get:
> ERROR: operator does not exist: character varying = integer Hint: No operator
> matches the given name and argument types. You might need to add explicit
> type casts.
> As this example is not minimal I was able to reproduce it with the following
> test in JdbcTests:
> {code:java}
> @Test void testFilterPush() {
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .query("SELECT * FROM \"foodmart\".\"sales_fact_1997\"" +
>" WHERE cast(? as varchar) = cast(? as varchar)")
> .planHasSql("SELECT *\n" +
> "FROM \"foodmart\".\"sales_fact_1997\"\n" +
> "WHERE cast(? as varchar) = cast(? as varchar)");
> }
> {code}
> The test shows the exact behaviour as it fails with the following:
> Caused by: java.sql.SQLSyntaxErrorException: data type cast needed for
> parameter or null literal in statement [SELECT *
> FROM "foodmart"."sales_fact_1997"
> WHERE ? = ?
> As can be seen in the exception message, the cast is also lost in this
> scenario
> To me it seems like an obvious bug, but maybe I am missing something here.
> I hope some1 can help :)
> BR,
> Corvin
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6534) Adjust type when pulling up Calc in JoinUnifyRule
[ https://issues.apache.org/jira/browse/CALCITE-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6534: Labels: pull-request-available (was: ) > Adjust type when pulling up Calc in JoinUnifyRule > - > > Key: CALCITE-6534 > URL: https://issues.apache.org/jira/browse/CALCITE-6534 > Project: Calcite > Issue Type: Improvement >Reporter: suibianwanwan >Assignee: suibianwanwan >Priority: Minor > Labels: pull-request-available > > In JoinOnLeftCalcUnifyRule, JoinOnRIghtCalcUnifyRule, JoinOnCalcUnifyRule, > calcite tries to pull up the calc operator to make Query equivalent to target > . In [CALCITE-6501|https://issues.apache.org/jira/browse/CALCITE-6501], for > the case where the assert is due to a difference in nullablity, we do an > early intercept and return null. This will result in some cases that can be > rewritten not being able to be rewritten. > We can fix nullablility if this rewrite maintains semantics -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6533) Division between integer and decimal produces incorrect result
[ https://issues.apache.org/jira/browse/CALCITE-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6533: Labels: pull-request-available (was: ) > Division between integer and decimal produces incorrect result > -- > > Key: CALCITE-6533 > URL: https://issues.apache.org/jira/browse/CALCITE-6533 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > The following program > SELECT 95.0 / 100 > produces the expected result, .95, as a DECIMAL(14, 8). > However, the program > SELECT 95 / 100.0 > produces the result 0E+! with type DECIMAL(17, -1) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-4838) add roundingMode in SqlConformance to document the rounding mode when cast an approximate numeric to int
[
https://issues.apache.org/jira/browse/CALCITE-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4838:
Labels: pull-request-available (was: )
> add roundingMode in SqlConformance to document the rounding mode when cast
> an approximate numeric to int
> -
>
> Key: CALCITE-4838
> URL: https://issues.apache.org/jira/browse/CALCITE-4838
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.27.0
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> According to the SQL Strandard about how to cast an approximate numeric to
> int in different database have different RoundingMode. for example:
> In PostgreSQL、Mysql、Oracle(RoundingMode.HALF_UP):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 6
> select cast(-5.5 as int) return -6{code}
> In Calcite、Sql Server 2008(RoundingMode.DOWN):
> {code:java}
> select cast(5.1 as int) return 5
> select cast(5.5 as int) return 5
> select cast(-5.5 as int) return -5
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6531) Correct Javadoc example in SqlStaticAggFunction#constant
[
https://issues.apache.org/jira/browse/CALCITE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6531:
Labels: pull-request-available (was: )
> Correct Javadoc example in SqlStaticAggFunction#constant
>
>
> Key: CALCITE-6531
> URL: https://issues.apache.org/jira/browse/CALCITE-6531
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.35.0, 1.36.0, 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The Javadoc in SqlStaticAggFunction#constant says:
> {noformat}
> GROUPING(deptno) expands to literal 1 if the aggregate has GROUP BY deptno
> {noformat}
> However, this "1" seems incorrect (it should rather be "0"). If we look at
> the actual implementation of this logic in
> [SqlGroupingFunction#constant|https://github.com/apache/calcite/blob/e4bbcd6f53ff6be2e2be0893b94d3806e58278d2/core/src/main/java/org/apache/calcite/sql/fun/SqlGroupingFunction.java#L62],
> or [this test
> agg.iq|https://github.com/apache/calcite/blob/e4bbcd6f53ff6be2e2be0893b94d3806e58278d2/core/src/test/resources/sql/agg.iq#L689],
> it seems in these cases the GROUPING is expanded to a constant 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6530) HTTP Sessions are never exipred in Avatica server
[ https://issues.apache.org/jira/browse/CALCITE-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6530: Labels: pull-request-available (was: ) > HTTP Sessions are never exipred in Avatica server > - > > Key: CALCITE-6530 > URL: https://issues.apache.org/jira/browse/CALCITE-6530 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Labels: pull-request-available > > Http Sessions created by the Avatica server are never expired. > This eventually causes the Avatica server to OOM. > Well designed clients using long-lived sessions may never generate enough > sessions between server restarts for this to become apparent, but ill-behaved > clients creating a lot of sessions can fill the heap in a short time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6527) Add DATE_ADD function (enabled in Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6527:
Labels: pull-request-available (was: )
> Add DATE_ADD function (enabled in Spark library)
>
>
> Key: CALCITE-6527
> URL: https://issues.apache.org/jira/browse/CALCITE-6527
> Project: Calcite
> Issue Type: New Feature
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
>
> https://spark.apache.org/docs/2.3.0/api/sql/index.html#date_add
> {code:java}
> > SELECT date_add('2016-07-30', 1);
> 2016-07-31
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6526) Refactor DEVELOCITY_ACCESS_KEY definition in one place
[
https://issues.apache.org/jira/browse/CALCITE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6526:
Labels: pull-request-available (was: )
> Refactor DEVELOCITY_ACCESS_KEY definition in one place
> --
>
> Key: CALCITE-6526
> URL: https://issues.apache.org/jira/browse/CALCITE-6526
> Project: Calcite
> Issue Type: Task
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Trivial
> Labels: pull-request-available
>
> The \{{DEVELOCITY_ACCESS_KEY}} environment variable definition is used in
> every CI job inside the main.yml file and it appears ~16 times. Instead of
> repeating the same definition multiple times we can set it only once for all
> jobs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6501) Assertion Error in JoinUnifyRule Due to Type Mismatch
[
https://issues.apache.org/jira/browse/CALCITE-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6501:
Labels: pull-request-available (was: )
> Assertion Error in JoinUnifyRule Due to Type Mismatch
> -
>
> Key: CALCITE-6501
> URL: https://issues.apache.org/jira/browse/CALCITE-6501
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: suibianwanwan
>Priority: Minor
> Labels: pull-request-available
> Attachments: image-2024-07-25-22-05-23-957.png
>
>
> In some cases, there is an assertion failure during the unifyRule rewriting
> process due to a type mismatch. If we can't rewrite it, we'd better return
> null instead of assert.
> example：
> {code:java}
> @Test
> public void testJoinOnCalcToJoin3011()
> {
> String mv = ""
> + "select \"emps\".\"empid\", \"emps\".\"deptno\", \"depts\".\"deptno\"
> from\n"
> + "\"emps\" right join \"depts\"\n"
> + "on \"emps\".\"deptno\" = \"depts\".\"deptno\"";
> String query = ""
> + "select \"A\".\"empid\", \"A\".\"a\", \"A\".\"deptno\",
> \"depts\".\"deptno\" from\n"
> + " (select \"empid\", \"deptno\", \"deptno\" \"a\" from \"emps\") A"
> + " right join \"depts\"\n"
> + "on \"A\".\"deptno\" = \"depts\".\"deptno\"";
> sql(mv, query).noMat();
> } {code}
> Trace:
> {code:java}
> type mismatch:type1:JavaType(int) NOT NULLtype2:JavaType(class
> java.lang.Integer)java.lang.AssertionError: type mismatch:type1:JavaType(int)
> NOT NULLtype2:JavaType(class java.lang.Integer) at
> org.apache.calcite.util.Litmus.lambda$static$0(Litmus.java:31) at
> org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2204) at
> org.apache.calcite.rex.RexProgramBuilder$RegisterInputShuttle.visitInputRef(RexProgramBuilder.java:949)
> at
> org.apache.calcite.rex.RexProgramBuilder$RegisterInputShuttle.visitInputRef(RexProgramBuilder.java:927)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:125) at
> org.apache.calcite.rex.RexProgramBuilder.registerInput(RexProgramBuilder.java:303)
> at
> org.apache.calcite.rex.RexProgramBuilder.addProject(RexProgramBuilder.java:213)
> at org.apache.calcite.rex.RexProgram.create(RexProgram.java:235) at
> org.apache.calcite.rex.RexProgram.create(RexProgram.java:204) at
> org.apache.calcite.plan.SubstitutionVisitor$JoinOnLeftCalcToJoinUnifyRule.apply(SubstitutionVisitor.java:1265)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:589)
> at
> org.apache.calcite.plan.SubstitutionVisitor.go(SubstitutionVisitor.java:523)
> at
> org.apache.calcite.test.MaterializedViewSubstitutionVisitorTest$1.optimize(MaterializedViewSubstitutionVisitorTest.java:88)
> at
> org.apache.calcite.test.MaterializedViewTester.checkNoMaterialize(MaterializedViewTester.java:94)
> at
> org.apache.calcite.test.MaterializedViewFixture.noMat(MaterializedViewFixture.java:60)
> at {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6508) Parse error when using scalar sub-query as operant to Array constructor function
[
https://issues.apache.org/jira/browse/CALCITE-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6508:
Labels: pull-request-available (was: )
> Parse error when using scalar sub-query as operant to Array constructor
> function
>
>
> Key: CALCITE-6508
> URL: https://issues.apache.org/jira/browse/CALCITE-6508
> Project: Calcite
> Issue Type: Bug
>Reporter: Ian Bertolacci
>Assignee: Ian Bertolacci
>Priority: Major
> Labels: pull-request-available
>
> Using a scalar subquery in the {{`ARRAY[ ... ]`}} function throws "parse
> failed: Query expression encountered in illegal context"
> (Calcite version 1.36)
> For example:
> {code:sql}
> select ARRAY[ (select 1) ]
> select ARRAY[ (select max(x) from table) ]
> {code}
> Is this something that can be configured or easily altered?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6522) MAP_KEYS and MAP_VALUES function should throw if a key value is null
[
https://issues.apache.org/jira/browse/CALCITE-6522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6522:
Labels: pull-request-available (was: )
> MAP_KEYS and MAP_VALUES function should throw if a key value is null
> --
>
> Key: CALCITE-6522
> URL: https://issues.apache.org/jira/browse/CALCITE-6522
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> scala> val df = spark.sql("select map_keys(map(null,0))");
> df: org.apache.spark.sql.DataFrame = [map_keys(map(NULL, 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)
> scala> val df = spark.sql("select map_values(map(cast(null as int),0, 'foo',
> 1))");
> df: org.apache.spark.sql.DataFrame = [map_values(map(CAST(NULL AS INT), 0,
> foo, 1)): 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)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6519) Non-aggregate query that uses measure in ORDER BY
[
https://issues.apache.org/jira/browse/CALCITE-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6519:
Labels: pull-request-available (was: )
> Non-aggregate query that uses measure in ORDER BY
> -
>
> Key: CALCITE-6519
> URL: https://issues.apache.org/jira/browse/CALCITE-6519
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
>
> As of CALCITE-4496, a non-aggregate query can use measures in its SELECT
> clause; this change would further allow a non-aggregate query to use measures
> in its ORDER BY clause.
> An example such query:
> {code}
> WITH empm AS
> (SELECT *, avg(sal) AS MEASURE avgSal FROM emp)
> SELECT avgSal, deptno
> FROM empm
> ORDER BY avgSal DESC LIMIT 3;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6518) ClassCastException during validation when loading multiple libraries
[
https://issues.apache.org/jira/browse/CALCITE-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6518:
Labels: pull-request-available (was: )
> ClassCastException during validation when loading multiple libraries
>
>
> Key: CALCITE-6518
> URL: https://issues.apache.org/jira/browse/CALCITE-6518
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> The following test added to CalciteSqlOperatorTest will cause a
> ClassCastException:
> {code:java}
> @Test void testLibraries() {
> SqlOperatorFixture sqlOperatorFixture = fixture();
> final SqlOperatorFixture f = sqlOperatorFixture.withOperatorTable(
> SqlLibraryOperatorTableFactory.INSTANCE
> .getOperatorTable(
> SqlLibrary.STANDARD,
> SqlLibrary.MYSQL,
> SqlLibrary.POSTGRESQL
> ));
> f.checkScalar("substr('a', 1, 2)", "a", "VARCHAR(1) NOT NULL");
> }
> {code}
> Here is the top of the stack trace:
> {code}
> class org.apache.calcite.sql.type.FamilyOperandTypeChecker cannot be cast to
> class org.apache.calcite.sql.type.SqlOperandMetadata
> (org.apache.calcite.sql.type.FamilyOperandTypeChecker and
> org.apache.calcite.sql.type.SqlOperandMetadata are in unnamed module of
> loader 'app')
> java.lang.ClassCastException: class
> org.apache.calcite.sql.type.FamilyOperandTypeChecker cannot be cast to class
> org.apache.calcite.sql.type.SqlOperandMetadata
> (org.apache.calcite.sql.type.FamilyOperandTypeChecker and
> org.apache.calcite.sql.type.SqlOperandMetadata are in unnamed module of
> loader 'app')
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.userDefinedFunctionCoercion(TypeCoercionImpl.java:601)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:313)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:231)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6789)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:6776)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:167)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:2006)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1993)
> at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:276)
> at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6446)
> at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:144)
> at org.apache.calcite.sql.SqlNode.validateExpr(SqlNode.java:275)
> at org.apache.calcite.sql.SqlOperator.validateCall(SqlOperator.java:474)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateCall(SqlValidatorImpl.java:6446)
> at org.apache.calcite.sql.SqlCall.validate(SqlCall.java:144)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1143)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:849)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.parseAndValidate(AbstractSqlTester.java:162)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.validateAndThen(AbstractSqlTester.java:250)
> {code}
> Calcite behaves correctly if either the MYSQL or the POSTGRES libraries are
> not supplied.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6433) SUBSTRING can return incorrect empty result for some parameters
[
https://issues.apache.org/jira/browse/CALCITE-6433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6433:
Labels: pull-request-available (was: )
> SUBSTRING can return incorrect empty result for some parameters
> ---
>
> Key: CALCITE-6433
> URL: https://issues.apache.org/jira/browse/CALCITE-6433
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Iurii Gerzhedovich
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> SUBSTRING function for cases when 3rd parameter (length) more than
> Integer.MAX_VALUE can return empty result due to code do clamp
> that value and after that it can't be more than Integer.MAX_VALUE.
> Simple way to reproduce :
> append into *SqlOperatorTest* smth like:
> {noformat}
> f.checkScalar(
> String.format("{fn SUBSTRING('abcdef', %d, %d)}", Integer.MIN_VALUE,
> 10L + Integer.MAX_VALUE),
> "abcdef",
> "VARCHAR(6) NOT NULL");
> {noformat}
> it`s all due to check after clamping
> {noformat}
> public static String substring(String c, int s, int l) {
>
> long e = (long) s + (long) l; -- here we can got incorrect length
> .
> if (s > lc || e < 1L) {
> return "";
> }
> .{noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6515) Remove constants describing which bugs have been fixed in Bug
[
https://issues.apache.org/jira/browse/CALCITE-6515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6515:
Labels: pull-request-available (was: )
> Remove constants describing which bugs have been fixed in Bug
> -
>
> Key: CALCITE-6515
> URL: https://issues.apache.org/jira/browse/CALCITE-6515
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Minor
> Labels: pull-request-available
>
> The constants in Bug.java:
> {code:java}
> /** Whether
> * https://issues.apache.org/jira/browse/CALCITE-6375";>[CALCITE-6375]
> * Fix failing quidem tests for FORMAT in CAST is fixed. */
> public static final boolean CALCITE_6375_FIXED = false; {code}
> {code:java}
> /** Whether * href="https://issues.apache.org/jira/browse/CALCITE/issues/CALCITE-6295";> *
> [CALCITE-6295] Support IS NOT NULL in Arrow adapter is fixed. */ public
> static final boolean CALCITE_6295_FIXED = false;
> {code}
> {code:java}
> /** Whether
> * https://issues.apache.org/jira/browse/CALCITE/issues/CALCITE-6296";>
> * [CALCITE-6296] Support IS NULL in Arrow adapter is fixed. */
> public static final boolean CALCITE_6296_FIXED = false;{code}
> These bugs have been fixed, so need to remove it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6514) Enable tests about AssertionError while translating IN list that contains null
[
https://issues.apache.org/jira/browse/CALCITE-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6514:
Labels: pull-request-available (was: )
> Enable tests about AssertionError while translating IN list that contains null
> --
>
> Key: CALCITE-6514
> URL: https://issues.apache.org/jira/browse/CALCITE-6514
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> /**
> * Whether http://issues.eigenbase.org/browse/FRG-327";>issue
> * FRG-327: AssertionError while translating IN list that contains null
> * is fixed.
> */
> public static final boolean FRG327_FIXED = false; {code}
> After the test, this issue has been fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6465) Rework code generator
[ https://issues.apache.org/jira/browse/CALCITE-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6465: Labels: pull-request-available (was: ) > Rework code generator > - > > Key: CALCITE-6465 > URL: https://issues.apache.org/jira/browse/CALCITE-6465 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: James Duong >Assignee: James Duong >Priority: Major > Labels: pull-request-available > > Holistically replace the (or provide a separate optional) code generator to > reduce issues such as CALCITE-3094 . > One suggestion in the comments for CALCITE-3094 has been to use the [code > generator from > Flink.|https://nightlies.apache.org/flink/flink-docs-release-1.3/api/java/org/apache/flink/table/codegen/CodeGenerator.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6513) FilterProjectTransposeRule may cause OOM when Project expressions are complex
[
https://issues.apache.org/jira/browse/CALCITE-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6513:
Labels: pull-request-available (was: )
> FilterProjectTransposeRule may cause OOM when Project expressions are complex
> -
>
> Key: CALCITE-6513
> URL: https://issues.apache.org/jira/browse/CALCITE-6513
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Krisztian Kasa
>Assignee: Krisztian Kasa
>Priority: Major
> Labels: pull-request-available
>
> CALCITE-3774 addresses preventing merging projects when the resulting
> expressions in the merged project are too complex and lead to slow
> compilation or out of memory.
> However, when there is a {{Filter}} on top of the {{Projects}} with a
> predicate referencing the complex expressions {{FilterProjectTransposeRule}}
> tries to push down the {{Filter}} below the bottom {{Project}} merging the
> expressions and causing OOM.
> The issue was initially reproduced using Hive with the Hive version of
> {{FilterProjectTransposeRule}}. See: HIVE-28264
> Calcite is also affected:
> [https://github.com/kasakrisz/calcite/commit/b35a02f368624a9c4768f348cd072a95ed6de3e1]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6506) Incorrect RelDataType generated for IN Subquery
[
https://issues.apache.org/jira/browse/CALCITE-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6506:
Labels: pull-request-available (was: )
> Incorrect RelDataType generated for IN Subquery
> ---
>
> Key: CALCITE-6506
> URL: https://issues.apache.org/jira/browse/CALCITE-6506
> Project: Calcite
> Issue Type: Bug
>Reporter: Brandon Chong
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> If a user writes a query like:
>
> {{select * from cp."iceberg/orders/orders.parquet" where o_orderkey IN (1,
> 2, 3)}}
> It get's rewritten to use a LogicalValues with RelDataType nullable INTEGER
> row type. The problem is that it's actually NOT NULL.
> You can see the issue in SqlToRelConverter:
>
> {{final RelDataType targetRowType =
> SqlTypeUtil.promoteToRowType(typeFactory,
> validator.getValidatedNodeType(leftKeyNode), null);
> final boolean notIn = call.getOperator().kind == SqlKind.NOT_IN;
> converted =
> convertExists(query, RelOptUtil.SubQueryType.IN, subQuery.logic,
> notIn, targetRowType);}}
> Note that it's using the type of the leftKeyNode and not right key node.
> For example: A IN (B, C, D) ... it's using typeof(A) instead of typeof(B, C,
> D).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6496) Enable tests from outer.iq
[
https://issues.apache.org/jira/browse/CALCITE-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6496:
Labels: pull-request-available (was: )
> Enable tests from outer.iq
> --
>
> Key: CALCITE-6496
> URL: https://issues.apache.org/jira/browse/CALCITE-6496
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Many tests in outer.iq are disabled with this comment:
> {code}
> # The following test is disabled, because we cannot handle non-equi-join.
> # Following it are the results from MySQL.
> !if (false) {
> {code}
> Most of these tests could probably be enabled, but they require minor
> formatting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6511) Migrate from Gradle Enterprise Gradle Plugin to Develocity Gradle Plugin
[ https://issues.apache.org/jira/browse/CALCITE-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6511: Labels: pull-request-available (was: ) > Migrate from Gradle Enterprise Gradle Plugin to Develocity Gradle Plugin > - > > Key: CALCITE-6511 > URL: https://issues.apache.org/jira/browse/CALCITE-6511 > Project: Calcite > Issue Type: Improvement >Reporter: Clay Johnson >Assignee: Clay Johnson >Priority: Minor > Labels: pull-request-available > > Currently, Calcite publishes build scans to the Develocity instance at > ge.apache.org. To accomplish this, the Gradle Enterprise Gradle Plugin is > applied. > As of Develocity 2024.3, expected later this year, the Gradle Enterprise > Gradle Plugin will no longer be supported. Migration to the Develocity Gradle > Plugin will be necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6480) OracleDialect does not support CASE WHEN returning boolean
[
https://issues.apache.org/jira/browse/CALCITE-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6480:
Labels: pull-request-available (was: )
> OracleDialect does not support CASE WHEN returning boolean
> --
>
> Key: CALCITE-6480
> URL: https://issues.apache.org/jira/browse/CALCITE-6480
> Project: Calcite
> Issue Type: Wish
> Components: core
>Reporter: kate
>Priority: Minor
> Labels: pull-request-available
>
> Our requirement is to use Calcite to translate queries into different
> dialects. During validation in the TPC-DS scenario, we found that {{Oracle}}
> does not support SQL statements like
> {code:java}
> SELECT * FROM xxx
> WHERE CASE WHEN a > 10 THEN b < 5 ELSE c > 0 END;{code}
> Therefore, we hope to remove such predicates at the dialect like Oracle.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6509) MongoAdapter throws 'Invalid JSON Number' exception if first character of field name is number
[
https://issues.apache.org/jira/browse/CALCITE-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6509:
Labels: pull-request-available (was: )
> MongoAdapter throws 'Invalid JSON Number' exception if first character of
> field name is number
> --
>
> Key: CALCITE-6509
> URL: https://issues.apache.org/jira/browse/CALCITE-6509
> Project: Calcite
> Issue Type: Bug
> Components: mongodb-adapter
>Affects Versions: 1.37.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
>
> MongoAdapter throws 'Invalid JSON Number' exception if first character of
> field name is number.
> Test case:
> {code}
> assertModel(MODEL)
> .query("select cast(_MAP['1_minute_aggregation'] as INT) as
> \"1_minute_aggregation\" "
> + "from \"mongo_raw\".\"datatypes\"")
> .queryContains(
> mongoChecker("{$project: {'1_minute_aggregation': 1}}"));
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5034) Disable Gradle build cache or use an alternative account for it
[ https://issues.apache.org/jira/browse/CALCITE-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-5034: Labels: pull-request-available (was: ) > Disable Gradle build cache or use an alternative account for it > --- > > Key: CALCITE-5034 > URL: https://issues.apache.org/jira/browse/CALCITE-5034 > Project: Calcite > Issue Type: Task > Components: build >Reporter: Vladimir Sitnikov >Assignee: Stamatis Zampetakis >Priority: Major > Labels: pull-request-available > Attachments: bucket-utilization-cache.csv > > > Calcite uses build cache since CALCITE-4140. > I'm paying for the service (~$6/month), and there's a risk bank will block > further payments (I'm from Russia :-/ ), so I think it is time to switch to > another account or disable the build-cache. > I've chosen Wasabi S3 since they have a free egress policy, so the costs are > predictable. > Cloudflare R2 is not ready yet: > https://blog.cloudflare.com/introducing-r2-object-storage/ > Rough stats so far > Total storage=15 GiB (~retention is 30 days) > Upload=0.1-0.2 GiB/day > Download=1-2 GiB/day -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6507) Random functions are incorrectly considered deterministic
[
https://issues.apache.org/jira/browse/CALCITE-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6507:
Labels: pull-request-available (was: )
> Random functions are incorrectly considered deterministic
> -
>
> Key: CALCITE-6507
> URL: https://issues.apache.org/jira/browse/CALCITE-6507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> {{{}RAND{}}}, {{{}RANDOM{}}}, and {{RAND_INTEGER}} don't override the
> {{isDeterministic}} method, so they get the default behavior, i.e. true,
> which is incorrect.
> This can lead to undesired consequences, e.g.:
> A) {{RelMetadataQuery#getPulledUpPredicates}} can consider them as constants
> (and place them inside {{{}RelOptPredicateList#constantMap{}}}) since
> {{RelMdPredicates}} calls {{{}RexUtil#isConstant{}}}, which uses a
> {{ConstantFinder}} that evaluates whether a RexCall is constant or not based
> on the operator's isDeterministic value.
> B) As a consequence of A) {{SortRemoveConstantKeyRule}} can incorrectly
> remove an "ORDER BY RAND()"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6478) JSON functions should return NULL when input is NULL
[
https://issues.apache.org/jira/browse/CALCITE-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6478:
Labels: pull-request-available (was: )
> JSON functions should return NULL when input is NULL
> -
>
> Key: CALCITE-6478
> URL: https://issues.apache.org/jira/browse/CALCITE-6478
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Here is the test in H2:
> {code:java}
> SELECT js,
>js IS JSON"json?",
>js IS JSON value "json?",
>js IS JSON SCALAR "scalar?",
>js IS JSON OBJECT "object?",
>js IS JSON ARRAY "array?"
> FROM (VALUES ('123'),
> ('"abc"'),
> ('{"a": "b"}'),
> ('[1,2]'),
> ('abc'), NULL) foo(js);
> {code}
> {code:java}
> +--+-+-+---+---+--+
> |JS|json?|json?|scalar?|object?|array?|
> +--+-+-+---+---+--+
> |123 |true |true |true |false |false |
> |"abc" |true |true |true |false |false |
> |{"a": "b"}|true |true |false |true |false |
> |[1,2] |true |true |false |false |true |
> |abc |false|false|false |false |false |
> |null |null |null |null |null |null |
> +--+-+-+---+---+--+
> {code}
> Same SQL in Calcite:
> {code:java}
> ++---+---+-+-++
> | JS | json? | json? | scalar? | object? | array? |
> ++---+---+-+-++
> | "abc" | true | true | true| false | false |
> | 123| true | true | true| false | false |
> | [1,2] | true | true | false | false | true |
> | abc| false | false | false | false | false |
> | {"a": "b"} | true | true | false | true| false |
> || false | false | false | false | false |
> ++---+---+-+-++
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6481) Optimize 'VALUES...UNION ALL...VALUES' to a single 'VALUES' the IN-list contains NULL and it is converted to VALUES
[
https://issues.apache.org/jira/browse/CALCITE-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6481:
Labels: pull-request-available (was: )
> Optimize 'VALUES...UNION ALL...VALUES' to a single 'VALUES' the IN-list
> contains NULL and it is converted to VALUES
> ---
>
> Key: CALCITE-6481
> URL: https://issues.apache.org/jira/browse/CALCITE-6481
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> The SQL:
> {code:java}
> with
> t1(a,y) as (select * from (values (1, 2), (3,
> null),(7369,null),(7499,30),(null, 20),(null, 5)) as t1)
> select *
> from t1
> where (t1.a,t1.y) in ((1, 2), (3, null),(7369,null),(7499,30),(null,
> 20),(null, 5));
> EnumerableHashJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[semi])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, null }, { 7369, null }, { 7499, 30
> }, { null, 20 }, { null, 5 }]])
> EnumerableUnion(all=[true])
> EnumerableValues(tuples=[[{ 3, null }]])
> EnumerableValues(tuples=[[{ 7369, null }]])
> EnumerableValues(tuples=[[{ null, 20 }]])
> EnumerableValues(tuples=[[{ null, 5 }]])
> EnumerableValues(tuples=[[{ 1, 2 }, { 7499, 30 }]])
> !plan
> with
> t1(a,y) as (select * from (values (1, 2), (3, 5),(7369,6),(7499,30),(2,
> 20),(3, 5)) as t1)
> select *
> from t1
> where (t1.a,t1.y) in ((1, 2), (3, 3),(7369,3),(7499,30),(1, 20),(3, 5));
> EnumerableHashJoin(condition=[AND(=($0, $2), =($1, $3))], joinType=[semi])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, 5 }, { 7369, 6 }, { 7499, 30 }, {
> 2, 20 }, { 3, 5 }]])
> EnumerableValues(tuples=[[{ 1, 2 }, { 3, 3 }, { 7369, 3 }, { 7499, 30 }, {
> 1, 20 }, { 3, 5 }]])
> !plan {code}
> If the IN-list includes NULL, Calcite will convert VALUES to UNION ALL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6502) Parser loses position information for Expression3
[
https://issues.apache.org/jira/browse/CALCITE-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6502:
Labels: pull-request-available (was: )
> Parser loses position information for Expression3
> -
>
> Key: CALCITE-6502
> URL: https://issues.apache.org/jira/browse/CALCITE-6502
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> Parser.jj features the following code snipped in the Expression3 production:
> {code:java}
> if (list1.size() == 1) {
> // interpret as single value or query
> return list1.get(0);
> }
> {code}
> This is problematic because the span of list1 is not the same as the span of
> its first element.
> This makes it look like the expression parsed does not include the opening
> and closing parens.
> This can be a problem for error reporting tools (but there are other use
> cases that may be impacted).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6498) Elasticsearch multi-field mappings do not work
[
https://issues.apache.org/jira/browse/CALCITE-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6498:
Labels: pull-request-available (was: )
> Elasticsearch multi-field mappings do not work
> --
>
> Key: CALCITE-6498
> URL: https://issues.apache.org/jira/browse/CALCITE-6498
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Reporter: Tim Grein
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> _EmbeddedElasticsearchPolicy#_
> _applyMapping_ tries to apply a multi-field mapping by adding another
> _properties_ field inside a parent field mapping. In Elasticsearch you need
> to use _fields_ rather than _properties_ for a multi-field mapping to work.
>
> I've tested this with ES 7 and ES 6 (only including ES 7 example here in the
> issue description; for ES 6 you need to wrap everything under "mappings" in
> "_doc"):
> ES 7:
> {code:java}
> PUT /some_index
> {
> "mappings": {
> "properties": {
> "some_field": {
> "type": "text",
> "properties": {
> "keyword": {
> "type": "keyword"
> }
> }
> }
> }
> }
> }{code}
> will lead to the following error:
> {code:java}
> {
> "error" : {
> "root_cause" : [
> {
> "type" : "mapper_parsing_exception",
> "reason" : "Mapping definition for [some_field] has unsupported
> parameters: [properties : {keyword={type=keyword}}]"
> }
> ],
> "type" : "mapper_parsing_exception",
> "reason" : "Failed to parse mapping [_doc]: Mapping definition for
> [some_field] has unsupported parameters: [properties :
> {keyword={type=keyword}}]",
> "caused_by" : {
> "type" : "mapper_parsing_exception",
> "reason" : "Mapping definition for [some_field] has unsupported
> parameters: [properties : {keyword={type=keyword}}]"
> }
> },
> "status" : 400
> } {code}
>
> Successful request:
> {code:java}
> PUT /some_index
> {
> "mappings": {
> "properties": {
> "some_field": {
> "type": "text",
> "fields": {
> "keyword": {
> "type": "keyword"
> }
> }
> }
> }
> }
> } {code}
> You'll encounter this error also, if you adapt the test data in
> _ElasticsearchAdapterTest_ to include nested fields:
> {code:java}
> @BeforeAll
> public static void setupInstance() throws Exception {
> // "city.keyword" is a nested field with type "keyword"
> final Map mapping =
> ImmutableMap.of("city", "text", "city.keyword", "keyword", "state",
> "keyword", "pop", "long"); {code}
> Error:
> {code:java}
> {...
> {"type":"mapper_parsing_exception","reason":"unknown parameter [properties]
> on mapper [city] of type [text]"}
> ...} {code}
> Looking at _ElasticsearchJson#visitMappingProperties_ I assume this will lead
> to a similar issue, which I'll double-check (we probably need to distinguish
> between nested fields and multi-field mappings explicitly).
> This is related to https://issues.apache.org/jira/browse/CALCITE-3027 as you
> want to detect, if you perform a "LIKE" operator on a purely "text" mapped
> field, which will lead to weird semantics ("text" mapped fields are
> analyzed/broken up into several tokens), if you do not prevent it. Usually
> you have a multi-field mapping for a field containing text ("text" mapping
> for full text search and a "keyword" mapping you can use for aggregations,
> wildcard queries etc.). So this is rather important to work correctly overall
> and in the tests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6471) Improve performance of SqlToRelConverter by preventing unconditional conversion of sqlNodes to string for null-check messages
[
https://issues.apache.org/jira/browse/CALCITE-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6471:
Labels: pull-request-available (was: )
> Improve performance of SqlToRelConverter by preventing unconditional
> conversion of sqlNodes to string for null-check messages
> --
>
> Key: CALCITE-6471
> URL: https://issues.apache.org/jira/browse/CALCITE-6471
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Minor
> Labels: pull-request-available
>
> Currently, {{SqlToRelConverter}} contains a few places where {{sqlNode}} is
> concatenated to some prefix and passed as plain string rather that message
> supplier as parameter to {{requireNonNull}} method. These are, namely, lines
> 1019, 4031, and 5344 at commit 29c413a3:
> {code:java}
> SqlNode elseOperand =
> requireNonNull(caseNode.getElseOperand(),
> "getElseOperand for " + caseNode);
> {code}
> {code:java}
> protected RelOptTable getTargetTable(SqlNode call) {
> final SqlValidatorNamespace targetNs = getNamespace(call);
> SqlValidatorNamespace namespace;
> if (targetNs.isWrapperFor(SqlValidatorImpl.DmlNamespace.class)) {
> namespace = targetNs.unwrap(SqlValidatorImpl.DmlNamespace.class);
> } else {
> namespace = targetNs.resolve();
> }
> RelOptTable table = SqlValidatorUtil.getRelOptTable(namespace,
> catalogReader, null, null);
> return requireNonNull(table, "no table found for " + call);
> }
> {code}
> {code:java}
> return Pair.of(c, (e, fieldName) -> {
> final int j = requireNonNull(fieldMap.get(fieldName), "field " +
> fieldName);
> return rexBuilder.makeFieldAccess(e, j);
> });
> {code}
> We can shave a few microseconds by simply replacing plain string with message
> supplier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6372) Support ASOF joins
[ https://issues.apache.org/jira/browse/CALCITE-6372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6372: Labels: pull-request-available (was: ) > Support ASOF joins > -- > > Key: CALCITE-6372 > URL: https://issues.apache.org/jira/browse/CALCITE-6372 > Project: Calcite > Issue Type: New Feature > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > > Seems that this new kind of JOIN named AS OF is very useful for processing > time-series data. Here is some example documentation from Snowflake: > https://docs.snowflake.com/en/sql-reference/constructs/asof-join > The semantics is similar to a traditional join, but the result always > contains at most one record from the left side, with the last matching > record on the right side (where "time" is any value that can be compared for > inequality). This can be expressed in SQL, but it looks very cumbersome, > using a JOIN, a GROUP BY, and then an aggregation to keep the last value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6497) Use helper setup method throughout whole ElasticsearchAdapterTest
[ https://issues.apache.org/jira/browse/CALCITE-6497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6497: Labels: pull-request-available (was: ) > Use helper setup method throughout whole ElasticsearchAdapterTest > - > > Key: CALCITE-6497 > URL: https://issues.apache.org/jira/browse/CALCITE-6497 > Project: Calcite > Issue Type: Improvement > Components: tests >Affects Versions: 1.37.0 >Reporter: Tim Grein >Assignee: Tim Grein >Priority: Trivial > Labels: pull-request-available > Fix For: 1.38.0 > > > There's a helper method `calciteAssert` inside the > `ElasticsearchAdapterTest`, which is responsible for setting up a connection > to Elasticsearch. This helper method is not used throughout the test class > consistently, which leads to code duplication and some manual setup code. We > should use the helper method to keep things consistent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6495) Allow ProjectSetOpTransposeRule to work with any subclass of Project
[
https://issues.apache.org/jira/browse/CALCITE-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6495:
Labels: pull-request-available (was: )
> Allow ProjectSetOpTransposeRule to work with any subclass of Project
>
>
> Key: CALCITE-6495
> URL: https://issues.apache.org/jira/browse/CALCITE-6495
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Even if the default configuration of ProjectSetOpTransposeRule matches a
> LogicalProject, theoretically any downstream project could adjust the rule
> config to match a different subclass of Project, with the corresponding
> RelBuilderFactory, to obtain the rule behavior customized for their needs.
> However, at this point this cannot work because
> ProjectSetOpTransposeRule#onMatch performs a
> {code:java}
> final LogicalProject origProject = call.rel(0);
> {code}
> which leads to a {{ClassCastException}} in this scenario.
> Therefore, this line should be changed (and generalized) into
> {code:java}
> final Project origProject = call.rel(0);
> {code}
> (as it happens already in other rules, such as FilterSetOpTransposeRule or
> ProjectFilterTransposeRule) to improve the rule's adaptability, without
> impacting the rule's behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6493) Improve Calcite development documentation
[ https://issues.apache.org/jira/browse/CALCITE-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6493: Labels: pull-request-available (was: ) > Improve Calcite development documentation > - > > Key: CALCITE-6493 > URL: https://issues.apache.org/jira/browse/CALCITE-6493 > Project: Calcite > Issue Type: Improvement > Components: site >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > > I noticed that in the jira submission process (like me), some terms are not > standardized, such as Mysql -> MySQL, arrow -> Spark. Thanks Julian for the > reminder > I think we can explain it in the document -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6490) Missing tests for SqlFunctions#overlay
[ https://issues.apache.org/jira/browse/CALCITE-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6490: Labels: pull-request-available (was: ) > Missing tests for SqlFunctions#overlay > -- > > Key: CALCITE-6490 > URL: https://issues.apache.org/jira/browse/CALCITE-6490 > Project: Calcite > Issue Type: Improvement > Components: tests >Affects Versions: 1.37.0 >Reporter: Tim Grein >Assignee: Tim Grein >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > After making some improvements to the OVERLAY operator docs in [Fix error > message typo and improve docs for OVERLAY > operator|https://github.com/apache/calcite/pull/3877] I've noticed that there > are no tests for SqlFunctions#overlay in SqlFunctionsTest. As checkString in > SqlOperatorTest doesn't check the actual value against the expected result > (at least that's how I understood it) I thought it's even more important to > add tests for the OVERLAY operator in SqlFunctionsTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6489) Add more data types to the Arrow test set
[ https://issues.apache.org/jira/browse/CALCITE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6489: Labels: pull-request-available (was: ) > Add more data types to the Arrow test set > - > > Key: CALCITE-6489 > URL: https://issues.apache.org/jira/browse/CALCITE-6489 > Project: Calcite > Issue Type: Sub-task >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > Currently, the Arrow test set only has basic data types, such as int, long, > etc., but does not have smallInt, tinyint, etc. > It is possible to improve the Arrow test set -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6488) Ensure collations created by RelCollations are canonized once
[ https://issues.apache.org/jira/browse/CALCITE-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6488: Labels: pull-request-available (was: ) > Ensure collations created by RelCollations are canonized once > - > > Key: CALCITE-6488 > URL: https://issues.apache.org/jira/browse/CALCITE-6488 > Project: Calcite > Issue Type: Task > Components: core >Affects Versions: 1.37.0 >Reporter: Ruben Q L >Assignee: Ruben Q L >Priority: Minor > Labels: pull-request-available > Fix For: 1.38.0 > > > RelCollations#of canonizes internally the result before returning it; however > some callers unnecessarily re-canonize the result on their end. > RelCollations#shift does not canonize its result, some callers canonize on > their end while others don't. > It is proposed to align their behaviour: RelCollations#of and > RelCollations#shift will canonize internally their results before return, so > that their callers do not need to do it on their end. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6485) AssertionError When an IN list containing NULL has an implicit coercion type converter
[
https://issues.apache.org/jira/browse/CALCITE-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6485:
Labels: pull-request-available (was: )
> AssertionError When an IN list containing NULL has an implicit coercion type
> converter
> --
>
> Key: CALCITE-6485
> URL: https://issues.apache.org/jira/browse/CALCITE-6485
> Project: Calcite
> Issue Type: Improvement
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> @Test void testInOperation() {
> sql("select 1 in (null, '2', '3') as f0 from (values (true, true,
> true))").ok();
> }
> {code}
> {code:java}
> Conversion to relational algebra failed to preserve datatypes:
> validated type:
> RecordType(BOOLEAN NOT NULL F0) NOT NULL
> converted type:
> RecordType(BOOLEAN F0) NOT NULL
> rel:
> LogicalValues(tuples=[[{ null }]]) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6487) TRIM function documentation refers to string1 two times
[
https://issues.apache.org/jira/browse/CALCITE-6487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6487:
Labels: newbie pull-request-available (was: newbie)
> TRIM function documentation refers to string1 two times
> ---
>
> Key: CALCITE-6487
> URL: https://issues.apache.org/jira/browse/CALCITE-6487
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Tim Grein
>Assignee: Tim Grein
>Priority: Trivial
> Labels: newbie, pull-request-available
>
> The docs for 'TRIM' state the following:
> "Removes the longest string containing only the characters in _string1_ from
> the start/end/both ends of _string1."_
>
> It should be the following to be accurate (changed last word from _string1_
> to {_}string2{_}):
> "Removes the longest string containing only the characters in _string1_ from
> the start/end/both ends of _string2."_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6145) Function 'TRIM' without parameters throw NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6145:
Labels: newbie pull-request-available (was: newbie)
> Function 'TRIM' without parameters throw NullPointerException
> -
>
> Key: CALCITE-6145
> URL: https://issues.apache.org/jira/browse/CALCITE-6145
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: SimonAlexs
>Assignee: Tim Grein
>Priority: Major
> Labels: newbie, pull-request-available
>
> When use sql as follow, trim without parameters, it throws
> java.lang.NullPointerException.
> {code:java}
> select trim(){code}
> Error position is org.apache.calcite.sql.SqlOperator#constructArgNameList.
> Source code is below. Line 5 "operand.getKind()" results in this exception.
>
> {code:java}
> protected @Nullable List constructArgNameList(SqlCall call) {
> // If any arguments are named, construct a map.
> final ImmutableList.Builder nameBuilder = ImmutableList.builder();
> for (SqlNode operand : call.getOperandList()) {
> if (operand.getKind() == SqlKind.ARGUMENT_ASSIGNMENT) {
> final List operandList = ((SqlCall) operand).getOperandList();
> nameBuilder.add(((SqlIdentifier) operandList.get(1)).getSimple());
> }
> }
> ImmutableList argNames = nameBuilder.build();
> if (argNames.isEmpty()) {
> return null;
> } else {
> return argNames;
> }
> } {code}
>
> Should it throw an exact description?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6295) Support IS NOT NULL in Arrow adapter
[
https://issues.apache.org/jira/browse/CALCITE-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6295:
Labels: pull-request-available (was: )
> Support IS NOT NULL in Arrow adapter
>
>
> Key: CALCITE-6295
> URL: https://issues.apache.org/jira/browse/CALCITE-6295
> Project: Calcite
> Issue Type: Sub-task
> Components: arrow-adapter
>Reporter: hongyu guo
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
>
> For example:
> {code:sql}
> select "intField", "stringField"
> from arrowdata
> where "intField" is not null
> order by "intField"
> limit 1
> {code}
> will throw an exception
> {code:java}
> java.lang.AssertionError: cannot translate IS NOT NULL($0)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch2(ArrowTranslator.java:131)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateAnd(ArrowTranslator.java:111)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch(ArrowTranslator.java:68)
> at
> org.apache.calcite.adapter.arrow.ArrowFilter.(ArrowFilter.java:43)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.convert(ArrowRules.java:97)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.onMatch(ArrowRules.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6475) RelToSql converter fails when the IN-list contains NULL and it is converted to VALUES
[
https://issues.apache.org/jira/browse/CALCITE-6475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6475:
Labels: pull-request-available (was: )
> RelToSql converter fails when the IN-list contains NULL and it is converted
> to VALUES
> -
>
> Key: CALCITE-6475
> URL: https://issues.apache.org/jira/browse/CALCITE-6475
> Project: Calcite
> Issue Type: Bug
>Reporter: xiong duan
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> The SQL
> {code:java}
> select * from "product" where ("product_id") in (12, null){code}
> When we convert the IN-list to OR condition, it can run successfully. But
> when we convert it to VALUES, it will throw NPE:
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.toSql(SqlImplementor.java:1468)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor.toSql(SqlImplementor.java:1416)
> at
> org.apache.calcite.rel.rel2sql.SqlImplementor$Context.toSql(SqlImplementor.java:702)
> at
> org.apache.calcite.rel.rel2sql.RelToSqlConverter.lambda$exprList$17(RelToSqlConverter.java:1158){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6483) Add length to PostgreSQL function library
[ https://issues.apache.org/jira/browse/CALCITE-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6483: Labels: pull-request-available (was: ) > Add length to PostgreSQL function library > - > > Key: CALCITE-6483 > URL: https://issues.apache.org/jira/browse/CALCITE-6483 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > PostgreSQL supports the *LENGTH* string function. > [https://www.postgresql.org/docs/14/functions-string.html] > Also check other libraries to see if those functions should be included. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6484) Sonar analysis fails intermittently due to OOM
[
https://issues.apache.org/jira/browse/CALCITE-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6484:
Labels: pull-request-available (was: )
> Sonar analysis fails intermittently due to OOM
> --
>
> Key: CALCITE-6484
> URL: https://issues.apache.org/jira/browse/CALCITE-6484
> Project: Calcite
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.37.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Major
> Labels: pull-request-available
>
> Sometimes the Sonar analysis fails due to OOM, here an [example of CI
> logs|https://ci-builds.apache.org/blue/organizations/jenkins/Calcite%2FCalcite-sonar/detail/PR-3858/9/pipeline/].
> In what follows the relevant extract:
> {code:java}
> The Daemon will expire after the build after running out of JVM heap space.
> The project memory settings are likely not configured or are configured to an
> insufficient value.
> The daemon will restart for the next build, which may increase subsequent
> build times.
> These settings can be adjusted by setting 'org.gradle.jvmargs' in
> 'gradle.properties'.
> The currently configured max heap space is '1 GiB' and the configured max
> metaspace is '512 MiB'.
> For more information on how to set these values, please refer to
> https://docs.gradle.org/8.7/userguide/build_environment.html#sec:configuring_jvm_memory
> in the Gradle documentation.
> To disable this warning, set
> 'org.gradle.daemon.performance.disable-logging=true'.
> > Task :sonar FAILED
> Build calcite FAILURE reason:
> Execution failed for task ':sonar':
> java.lang.OutOfMemoryError: Java heap space
> at B.A.A.A.A.F.(na:2438)
> at B.A.A.A.A.D$_D.(na:1146)
> at B.A.A.A.A.D.iterator(na:1079)
> at com.sonarsource.A.A.E.G$_C.D(na:2233)
> at com.sonarsource.A.A.C.E.A(na:972)
> at com.sonarsource.A.A.C.E.C(na:2276)
> at com.sonarsource.A.A.C.E.B(na:3115)
> at com.sonarsource.A.A.Y.A(na:3332)
> at com.sonarsource.A.A.Y.A(na:2596)
> at com.sonarsource.A.A.Y.E(na:1668)
> at com.sonarsource.A.A.Y.A(na:943)
> at com.sonarsource.A.A.Y.A(na:377)
> at com.sonarsource.A.A.Y.A(na:2750)
> at com.sonarsource.A.H.executeChecksOnFunction(na:1449)
> at com.sonarsource.A.H.executeChecks(na:2587)
> at com.sonarsource.A.H.executeSensor(na:3171)
> at com.sonarsource.A.H.execute(na:1926)
> at
> org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:63)
> at
> org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
> at
> org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:51)
> at
> org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:192)
> at
> org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:188)
> at
> org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:159)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.bootstrap.ScannerContainer.doAfterStart(ScannerContainer.java:399)
> at
> org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
> at
> org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
> at
> org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:131)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':sonar'.
> > Java heap space {code}
> At the top of the quoted text, it's recommended to increase the memory
> settings via the parameter 'org.gradle.jvmargs' in 'gradle.properties'.
> Since most of the time the analysis succeeds, we probably need a small
> increment at first to see if the situation improves (max heap space is now '1
> GiB', max metaspace is '512 MiB').
> It's detrimental to have CI failures as they not only deprive us from the
> sonar analysis, but they also contributed to the sentiment that flakyness in
> CI
[jira] [Updated] (CALCITE-6482) OracleDialect support bool literal as predicate
[ https://issues.apache.org/jira/browse/CALCITE-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6482: Labels: pull-request-available (was: ) > OracleDialect support bool literal as predicate > --- > > Key: CALCITE-6482 > URL: https://issues.apache.org/jira/browse/CALCITE-6482 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: kate >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6472) Add degree based trig functions to PostgreSQL function library
[ https://issues.apache.org/jira/browse/CALCITE-6472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6472: Labels: pull-request-available (was: ) > Add degree based trig functions to PostgreSQL function library > -- > > Key: CALCITE-6472 > URL: https://issues.apache.org/jira/browse/CALCITE-6472 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Minor > Labels: pull-request-available > > PostgreSQL supports the following trigonometric functions that are degree > based. > * COSD > * SIND > * TAND > * ACOSD > * ASIND > * ATAND -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6474) Aggregate with constant key can get a RowCount greater than its MaxRowCount
[
https://issues.apache.org/jira/browse/CALCITE-6474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6474:
Labels: pull-request-available (was: )
> Aggregate with constant key can get a RowCount greater than its MaxRowCount
> ---
>
> Key: CALCITE-6474
> URL: https://issues.apache.org/jira/browse/CALCITE-6474
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> An Aggregate with constant key can get a RowCount greater than its
> MaxRowCount.
> The root cause is that this logic in RelMdMaxRowCount
> {code}
> // Aggregate with constant GROUP BY always returns 1 row
> if (rel.getGroupType() == Aggregate.Group.SIMPLE) {
> final RelOptPredicateList predicateList =
> mq.getPulledUpPredicates(rel.getInput());
> if (!RelOptPredicateList.isEmpty(predicateList)
> && allGroupKeysAreConstant(rel, predicateList)) {
> return 1D;
> }
> }
> {code}
> is not applied in RelMdRowCount.
> Therefore we can get an Aggregate whose MaxRowCount is 1, but its RowCount is
> X (> 1).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6473) HAVING clauses may not contain window functions
[
https://issues.apache.org/jira/browse/CALCITE-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6473:
Labels: pull-request-available (was: )
> HAVING clauses may not contain window functions
> ---
>
> Key: CALCITE-6473
> URL: https://issues.apache.org/jira/browse/CALCITE-6473
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> according to the standard:
> {code}
> The shall not contain a without an
> intervening .
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6296) Support IS NULL in Arrow adapter
[
https://issues.apache.org/jira/browse/CALCITE-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6296:
Labels: pull-request-available (was: )
> Support IS NULL in Arrow adapter
>
>
> Key: CALCITE-6296
> URL: https://issues.apache.org/jira/browse/CALCITE-6296
> Project: Calcite
> Issue Type: Sub-task
> Components: arrow-adapter
>Reporter: hongyu guo
>Assignee: Tim Grein
>Priority: Major
> Labels: pull-request-available
>
> {code:sql}
> select "intField", "stringField"
> from arrowdata
> where "intField" is null
> {code}
> will throw an exception
> {code:java}
> java.lang.AssertionError: cannot translate IS NULL($0)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch2(ArrowTranslator.java:131)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateAnd(ArrowTranslator.java:111)
> at
> org.apache.calcite.adapter.arrow.ArrowTranslator.translateMatch(ArrowTranslator.java:68)
> at
> org.apache.calcite.adapter.arrow.ArrowFilter.(ArrowFilter.java:43)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.convert(ArrowRules.java:97)
> at
> org.apache.calcite.adapter.arrow.ArrowRules$ArrowFilterRule.onMatch(ArrowRules.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6470) Run specific JMH benchmarks without modifying sources
[
https://issues.apache.org/jira/browse/CALCITE-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6470:
Labels: pull-request-available (was: )
> Run specific JMH benchmarks without modifying sources
> -
>
> Key: CALCITE-6470
> URL: https://issues.apache.org/jira/browse/CALCITE-6470
> Project: Calcite
> Issue Type: Improvement
> Components: build
>Reporter: Stamatis Zampetakis
>Assignee: Stamatis Zampetakis
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> Currently we can run *all* JMH benchmarks of the project using the "jmh"
> Gradle task.
> {code:java}
> ./gradlew :ubenchmark:jmh
> {code}
> In many cases, we don't want to run all benchmarks but only one (or few) and
> this is not possible without modifying the Gradle build files (see
> https://github.com/melix/jmh-gradle-plugin/issues/152).
> The goal of this ticket is to add a (project) property (i.e., jmh.includes)
> to select the desired benchmarks via a regular expression that can be passed
> in the command line.
> {code:java}
> ./gradlew :ubenchmark:jmh -Pjmh.includes=ParserBenchmark
> {code}
> For example, the command above would run only the ParserBenchmark.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6464) Type inference for DECIMAL division seems incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6464: Labels: pull-request-available (was: ) > Type inference for DECIMAL division seems incorrect > --- > > Key: CALCITE-6464 > URL: https://issues.apache.org/jira/browse/CALCITE-6464 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Mihai Budiu >Assignee: Tim Grein >Priority: Minor > Labels: pull-request-available > > This bug surfaces if one uses a custom type system, e.g., where DECIMAL is > limited to (28, 10). > The problem is in RelDataTypeSystem.deriveDecimalDivideType. > The JavaDoc of this function gives the algorithm for deriving the division > result type. > According to these rules, if you divide two numbers of type DECIMAL(28, 10), > you should get a result with type DECIMAL(28, 10). > But the actual implementation infers a type of DECIMAL(28, 0), which seems > incorrect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6468) RelDecorrelator throws AssertionError if correlated variable is used as Aggregate group key
[
https://issues.apache.org/jira/browse/CALCITE-6468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6468:
Labels: pull-request-available (was: )
> RelDecorrelator throws AssertionError if correlated variable is used as
> Aggregate group key
> ---
>
> Key: CALCITE-6468
> URL: https://issues.apache.org/jira/browse/CALCITE-6468
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The problem can be reproduced with this query (a "simplified" version of
> TPC-DS query1):
> {code:sql}
> WITH agg_sal AS
> (SELECT deptno, sum(sal) AS total FROM emp GROUP BY deptno)
> SELECT 1 FROM agg_sal s1
> WHERE s1.total > (SELECT avg(total) FROM agg_sal s2 WHERE s1.deptno =
> s2.deptno)
> {code}
> If we apply subquery program, FilterAggregateTransposeRule and then we call
> the RelDecorrelator, it will fail with:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:581)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:495)
> ...
> {noformat}
> The problem appears in this assert (RelDecorrelator.java:581):
> {code}
> assert newPos == newInputOutput.size();
> {code}
> The root cause seems to be that, a few lines before, when processing the
> correlating variables from {{corDefOutputs}} a certain value is inserted in
> {{mapNewInputToProjOutputs}}:
> {code}
> if (!frame.corDefOutputs.isEmpty()) {
> for (Map.Entry entry : frame.corDefOutputs.entrySet()) {
> RexInputRef.add2(projects, entry.getValue(), newInputOutput);
> corDefOutputs.put(entry.getKey(), newPos);
> mapNewInputToProjOutputs.put(entry.getValue(), newPos); // <-- HERE
> newPos++;
> }
> }
> {code}
> The problem is that this value was already in the map, as it had been
> inserted previously as part of the group key processing:
> {code}
> for (int i = 0; i < oldGroupKeyCount; i++) {
> final int idx = groupKeyIndices.get(i);
> ...
> // add mapping of group keys.
> outputMap.put(idx, newPos);
> int newInputPos = requireNonNull(frame.oldToNewOutputs.get(idx));
> RexInputRef.add2(projects, newInputPos, newInputOutput);
> mapNewInputToProjOutputs.put(newInputPos, newPos); // <-- HERE added firstly
> newPos++;
> }
> {code}
> Therefore, the unnecessary insertion into {{mapNewInputToProjOutputs}} and
> the subsequent increment of {{newPos}} when the {{CorDef}}s are processed
> leads to the mismatch.
> Notice how, right before the assertion, when processing the remaining fields,
> it is verified that the value is not already contained on the
> {{mapNewInputToProjOutputs}}:
> {code}
> // add the remaining fields
> final int newGroupKeyCount = newPos;
> for (int i = 0; i < newInputOutput.size(); i++) {
> if (!mapNewInputToProjOutputs.containsKey(i)) { // <-- HERE checked
> RexInputRef.add2(projects, i, newInputOutput);
> mapNewInputToProjOutputs.put(i, newPos);
> newPos++;
> }
> }
> {code}
> Thus, probably the solution would be to apply the same logic when the CorDef
> are processed:
> {code}
> if (!frame.corDefOutputs.isEmpty()) {
> for (Map.Entry entry : frame.corDefOutputs.entrySet()) {
> final Integer pos = mapNewInputToProjOutputs.get(entry.getValue()); //
> <-- HERE add map verification
> if (pos == null) {
> RexInputRef.add2(projects, entry.getValue(), newInputOutput);
> corDefOutputs.put(entry.getKey(), newPos);
> mapNewInputToProjOutputs.put(entry.getValue(), newPos);
> newPos++;
> } else {
> corDefOutputs.put(entry.getKey(), pos);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6466) Sql Parsers instantiation is slow
[
https://issues.apache.org/jira/browse/CALCITE-6466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6466:
Labels: pull-request-available (was: )
> Sql Parsers instantiation is slow
> -
>
> Key: CALCITE-6466
> URL: https://issues.apache.org/jira/browse/CALCITE-6466
> Project: Calcite
> Issue Type: Improvement
>Reporter: Cyril de Catheu
>Priority: Minor
> Labels: pull-request-available
>
> *Summary:*
> Sql Parsers instantiation is slow because it instantiates a Throwable with a
> stacktrace.
> The speed of instantiation also depends on the call stack depth at the time
> of instantiation. The deeper in the call stack, the slower the instantiation.
> *Analysis:*
> This is an issue caused by JavaCC. The issue is fixed in newer version of
> JavaCC.
> Once JavaCC is upgraded to 7.0.13
> (https://issues.apache.org/jira/browse/CALCITE-5541), this benchmark can be
> re-run.
> See full discussion here:
> [https://lists.apache.org/thread/xw35sdy1w1k8lvn1q1lr7xb93bkj0lpq]
> {*}TODO{*}:
> Add a benchmark to measure the evolution of this issue.
> The benchmark can be re-run once
> https://issues.apache.org/jira/browse/CALCITE-5541 is done.
> Expected improvements are:
> - a minor speed improvement of ~10% for all parsers impacted by the issue
> - the instantiation of parsers should not depend on the call stack depth
> anymore
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-1012) Benchmark SQL parser
[ https://issues.apache.org/jira/browse/CALCITE-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-1012: Labels: pull-request-available (was: ) > Benchmark SQL parser > > > Key: CALCITE-1012 > URL: https://issues.apache.org/jira/browse/CALCITE-1012 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > Labels: pull-request-available > Attachments: allocations1.png, allocations2.png, allocations3.png, > allocations4.png > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6454) Implement array comparison operators
[
https://issues.apache.org/jira/browse/CALCITE-6454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6454:
Labels: pull-request-available (was: )
> Implement array comparison operators
>
>
> Key: CALCITE-6454
> URL: https://issues.apache.org/jira/browse/CALCITE-6454
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Norman Jordan
>Assignee: Norman Jordan
>Priority: Major
> Labels: pull-request-available
>
> The comparison operators <, <=, >, >=, =, <> are not implemented for arrays.
> Here is an example query:
>
> {code:java}
> SELECT array[2, 2] > array[1, 1]; {code}
> [This
> page|https://popsql.com/learn-sql/postgresql/how-to-compare-arrays-in-postgresql]
> describes how the comparisons work in PostgreSQL.
>
> Check if the comparison operators for arrays exist in other DB engines.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6462) VolcanoPlanner internal valid may throw exception when log trace is enabled
[
https://issues.apache.org/jira/browse/CALCITE-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6462:
Labels: pull-request-available (was: )
> VolcanoPlanner internal valid may throw exception when log trace is enabled
> ---
>
> Key: CALCITE-6462
> URL: https://issues.apache.org/jira/browse/CALCITE-6462
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Unit test in JdbcAdapterTest:
> {code:java}
> @Test void testAioob_5() {
> CalciteAssert.model(JdbcTest.SCOTT_MODEL)
> .query("select *\n"
> + "from scott.emp e left join scott.dept d\n"
> + "on 'job' in (select job from scott.bonus b)")
> .runs();
> }{code}
> Exceptions:
> {code:java}
> RelSubset [rel#108:RelSubset#7.ENUMERABLE.[]] has wrong best cost {1254.5
> rows, 340.5 cpu, 0.0 io}. Correct cost is {1752.0 rows, 337.5 cpu, 0.0
> io}{code}
> The best RelNode and the bestCode is different.
> When log trace is enabled, Tte code will be run:
> {code:java}
> if (LOGGER.isDebugEnabled()) {
> assert isValid(Litmus.THROW);
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6460) SortRemoveConstantKeysRule fails with AssertionError due to mismatched collation on resulting Sort
[
https://issues.apache.org/jira/browse/CALCITE-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6460:
Labels: pull-request-available (was: )
> SortRemoveConstantKeysRule fails with AssertionError due to mismatched
> collation on resulting Sort
> --
>
> Key: CALCITE-6460
> URL: https://issues.apache.org/jira/browse/CALCITE-6460
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ruben Q L
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> When {{SortRemoveConstantKeysRule}} is applied, at the end of the process it
> creates the resulting Sort with the new collation (which has removed the
> constant keys from the original one):
> {code}
> final Sort result =
> sort.copy(sort.getTraitSet(), input,
> RelCollations.of(collationsList));
> {code}
> However, if there's a collation defined inside's the Sort's traitSet, this
> copy will fail, because there will be a mismatch between the (original)
> collation in the traitSet (which is unchanged at the moment of the copy) and
> the new collation that has been computed by the rule (removing constant keys):
> {noformat}
> traits=NONE.[1, 2 DESC], collation=[2 DESC]
> java.lang.AssertionError: traits=NONE.[1, 2 DESC], collation=[2 DESC]
> at org.apache.calcite.rel.core.Sort.(Sort.java:87)
> at
> org.apache.calcite.rel.logical.LogicalSort.(LogicalSort.java:48)
> at org.apache.calcite.rel.logical.LogicalSort.copy(LogicalSort.java:81)
> at org.apache.calcite.rel.core.Sort.copy(Sort.java:150)
> at
> org.apache.calcite.rel.rules.SortRemoveConstantKeysRule.onMatch(SortRemoveConstantKeysRule.java:85)
> ...
> {noformat}
> This problem only happens if the traitSet includes
> {{RelCollationTraitDef.INSTANCE}}, so it can be unnoticed in many cases.
> However, we can reproduce it by adjusting
> {{RelOptRulesTest#testSortRemovalOneKeyConstant}}:
> {code}
> sql(sql)
> .withVolcanoPlanner(false, p -> {
> p.addRelTraitDef(RelCollationTraitDef.INSTANCE);
> RelOptUtil.registerDefaultRules(p, false, false);
> })
> .withRule(CoreRules.SORT_REMOVE_CONSTANT_KEYS)
> .check();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6448) FilterReduceExpressionsRule returns empty RelNode for RexLiterals
[
https://issues.apache.org/jira/browse/CALCITE-6448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6448:
Labels: pull-request-available (was: )
> FilterReduceExpressionsRule returns empty RelNode for RexLiterals
> -
>
> Key: CALCITE-6448
> URL: https://issues.apache.org/jira/browse/CALCITE-6448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Soumyakanti Das
>Assignee: Soumyakanti Das
>Priority: Major
> Labels: pull-request-available
>
> In Hive, for simple queries with {{WHERE 'foo'}} we get an empty result,
> where as for simple queries with {{WHERE t.stringColumn}} we get non-empty
> result.
> Currently in {{FilterReduceExpressionsRule}}, all {{RexLiteral}}s are
> converted to empty values by
> {code:java}
> else if (newConditionExp instanceof RexLiteral
> || RexUtil.isNullLiteral(newConditionExp, true)) {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> {code}
> This might be not inline with {{RexLiteral#isAlwaysFalse}}, and it might be
> safer to leave the literal as it is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6413) SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for both NATURAL and USING join conditions
[
https://issues.apache.org/jira/browse/CALCITE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6413:
Labels: pull-request-available (was: )
> SqlValidator does not invoke TypeCoercionImpl::binaryComparisonCoercion for
> both NATURAL and USING join conditions
> ---
>
> Key: CALCITE-6413
> URL: https://issues.apache.org/jira/browse/CALCITE-6413
> Project: Calcite
> Issue Type: Improvement
>Reporter: Maksim Zhuravkov
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: pull-request-available
>
> This can be observed by adding these test cases to `SqlToRelConverterTest`:
> 1. Join condition ON expression
> {code:java}
> @Test void test1() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno) ON
> emp.deptno = t.deptno";
> sql(sql).ok();
> }
> {code}
> 2. Common columns (USING/NATURAL) (since they both share the same code path
> for building join condition)
> {code:java}
> @Test void test2() {
> final String sql = "select * from emp JOIN (VALUES ('XXX')) t(deptno)
> USING (deptno)";
> sql(sql).ok();
> }
> {code}
> When test 1 runs, the SqlValidator calls
> TypeCoercionImpl::binaryComparisonCoercion
> When test 2 runs, the SqlValidator does not call
> TypeCoercionImpl::binaryComparisonCoercion.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6435) SqlToRel conversion of IN expressions may lead to incorrect simplifications
[
https://issues.apache.org/jira/browse/CALCITE-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6435:
Labels: pull-request-available (was: )
> SqlToRel conversion of IN expressions may lead to incorrect simplifications
> ---
>
> Key: CALCITE-6435
> URL: https://issues.apache.org/jira/browse/CALCITE-6435
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> the query must have the following features:
> * not all columns are selected
> ** to enable {{RelFieldTrimmer}} to start a cycle
> * two equivalent eq filters
> ** one in {{IN}} form ({{ename in ( 'Sebastian' )}})
> ** a regular {{=}} ({{ename = 'Sebastian'}})
> * an unrelated filter like {{deptno < 100}}
> the optimizer should more-or-less start with the `RelFieldTrimmer`
> the issue happens like:
> * at parse time both literals are parsed as {{CHAR( n )}}
> * the number of values in the `IN` is below `inSubqueryThreshold` - so it
> gets converted to a set of `=` filters
> ** expression is converted to OR form
> ** during conversion
> [SqlToRelConverter#ensureSqlType|https://github.com/apache/calcite/blob/fb15511e76c660cbd440578421645ebe63941bf7/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L1777-L1779]
> is called
> *** which skips the conversion for *CHAR / VARCHAR*
> * the *=* filter goes thru the "regular" rex conversion - which involves
> calling *rexBuilder#ensureType*
> * the filter condition contains *ename = 'Sebastian'* twice; however the
> types differ
> * *RelFieldTrimmer* starts a change cycle ; which induces the simplification
> of the filter condition
> * *RexSimplify* is executed with predicate elimination disabled (this will
> be important)
> * simplification compares the two literals with
> [equals|https://github.com/apache/calcite/blob/fb15511e76c660cbd440578421645ebe63941bf7/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1685]
> and returns `false`
> workarounds:
> * disable the conversion by setting *inSubqueryThreshold=1*
> * run a rule which executes `RexSimplify` with predicate elimination enabled
> earlier than the trimmer (ex: *ReduceExpressionsRule*)
> ** I think this bug remained hidden because this might happen easily
> testcase for `RelOptRulesTest`
> {code:java}
> @Test void testIncorrectInType() {
> final String sql = "select ename from emp "
> + " where ename in ( 'Sebastian' ) and ename = 'Sebastian' and
> deptno < 100";
> sql(sql)
> .withTrim(true)
> .withRule()
> .checkUnchanged();
> }
> {code}
> results in plan
> {code:java}
> LogicalProject(ENAME=[$0])
> LogicalValues(tuples=[[]])
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6450) Postgres CONCAT_WS function throws exception when parameter type is (, )
[
https://issues.apache.org/jira/browse/CALCITE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6450:
Labels: pull-request-available (was: )
> Postgres CONCAT_WS function throws exception when parameter type is
> (, )
>
>
> Key: CALCITE-6450
> URL: https://issues.apache.org/jira/browse/CALCITE-6450
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.37.0
>Reporter: xiong duan
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2024-06-29-14-57-56-513.png
>
>
> The SQL can run success in Postgres:
> {code:java}
> select concat_ws(',',ARRAY[1, 1, 1, 1]); {code}
> But in Calcite, It will throw exception:
> {code:java}
> @Test void testConcatFunction() {
> final String sql = "select concat_ws(',',ARRAY[1, 1, 1, 1])
> as c";
> fixture()
> .withFactory(c ->
> c.withOperatorTable(t ->
> SqlValidatorTest.operatorTableFor(SqlLibrary.POSTGRESQL)))
> .withCatalogReader(MockCatalogReaderExtended::create)
> .withSql(sql)
> .ok();
> }{code}
> {code:java}
> From line 1, column 8 to line 1, column 55: Cannot apply 'CONCAT_WS' to
> arguments of type 'CONCAT_WS(, )'. Supported form(s):
> 'CONCAT_WS()'{code}
> This issue find in comment
> [CALCITE-6446|https://github.com/apache/calcite/pull/3831] .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6451) Improve Nullability Derivation for Intersect and Minus
[
https://issues.apache.org/jira/browse/CALCITE-6451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6451:
Labels: pull-request-available (was: )
> Improve Nullability Derivation for Intersect and Minus
> --
>
> Key: CALCITE-6451
> URL: https://issues.apache.org/jira/browse/CALCITE-6451
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Victor Barua
>Assignee: Victor Barua
>Priority: Minor
> Labels: pull-request-available
>
> SetOp overrides `deriveRowType()` and computes the output row type to be the
> least restrictive across all inputs
> [here|https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rel/core/SetOp.java#L116-L127].
>
> So for example given
> {code:java}
> Input 1: (I64, I64, I64?, I64?)
> Input 2: (I64, I64?, I64, I64?) {code}
> where ? denotes nullable, the least restrictive output computes:
> {code:java}
> Output: (I64, I64?, I64?, I64?) {code}
> For UNION operations, these nullabilities are accurate.
> However for MINUS and INTERSECT there is room for improvement.
> *MINUS* only returns rows from the first input, as such its output
> nullability should always match that of its first input:
> {code:java}
> Output: (I64, I64, I64?, I64?) {code}
> *INTERSECT* only returns rows that match across all inputs. If a column is
> not nullable in any of the inputs, then it is not nullable in the output
> because no rows can be emitted in which that column is null:
> {code:java}
> Output: (I64, I64, I64, I64?) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6457) The array_contains function return false when arrayComponentType and op1 type are different
[ https://issues.apache.org/jira/browse/CALCITE-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6457: Labels: pull-request-available (was: ) > The array_contains function return false when arrayComponentType and op1 > type are different > > > Key: CALCITE-6457 > URL: https://issues.apache.org/jira/browse/CALCITE-6457 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.37.0 >Reporter: Caican Cai >Priority: Major > Labels: pull-request-available > > In Spark, array_contains(array(1.0, 2), 1) returns true because Spark > converts array and op1 types to the biggesttype. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6401) JDBC adapter cannot push down joins with complex JOIN condition
[
https://issues.apache.org/jira/browse/CALCITE-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6401:
Labels: pull-request-available (was: )
> JDBC adapter cannot push down joins with complex JOIN condition
> ---
>
> Key: CALCITE-6401
> URL: https://issues.apache.org/jira/browse/CALCITE-6401
> Project: Calcite
> Issue Type: Improvement
>Affects Versions: 1.36.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
>
> JDBC adapter (in JdbcJoinRule) cannot push down joins with conditions which
> include operations not listed in {{JdbcJoinRule::canJoinOnCondition}}.
> See also CALCITE-4907
> For example the following statement is executed using an
> {{EnumerableNestedLoopJoin}}
> {code:SQL}
> SELECT
> *
> FROM
>A
> JOIN (
> SELECT
> D."userId",
> MAX(D."id") as "id"
> FROM
>D
> GROUP BY
> D."userId"
> ) B ON (
> A."id" = B."id" AND A."userId" IS NOT NULL
> )
> OR (
> A."userId" = B."userId" AND A."id" IS NOT NULL
> )
> {code}
> Adding the cases {{IS_NULL}} and {{IS_NOT_NULL}} to
> {{JdbcJoinRule::canJoinOnCondition}} fixes the problem for this statement.
> But I was not able to find out which cases are also missing here. E.g. a join
> condition which compares a RexInputRef with a RexLiteral also fails.
> Where could I find the associated code in {{JdbcJoin::implement}} that makes
> it impossible to create an appropriate SQL statement if all operations were
> allowed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6436) JDBC adapter generates SQL missing parentheses when comparing 3 values with the same precedence like (a=b)=c
[
https://issues.apache.org/jira/browse/CALCITE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6436:
Labels: pull-request-available (was: )
> JDBC adapter generates SQL missing parentheses when comparing 3 values with
> the same precedence like (a=b)=c
>
>
> Key: CALCITE-6436
> URL: https://issues.apache.org/jira/browse/CALCITE-6436
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.37.0
>Reporter: Ulrich Kramer
>Assignee: xiong duan
>Priority: Major
> Labels: pull-request-available
>
> Running the following unit test in {{JdbcAdapterTest}} fails with
> {code:java}
> @Test void testOperatorInWhere() {
> CalciteAssert.model(FoodmartSchema.FOODMART_MODEL)
> .query("select * from \"sales_fact_1997\" "
> + "where (\"product_id\" = 1) = ?")
> .consumesPreparedStatement(p -> p.setBoolean(1, true))
> .runs();
> }
> {code}
> {noformat}
> Caused by: java.sql.SQLSyntaxErrorException: unexpected token: = : line: 3 in
> statement [SELECT *
> FROM "foodmart"."sales_fact_1997"
> WHERE "product_id" = 1 = ?
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6453) Simplify casts which are result of constant reduction
[
https://issues.apache.org/jira/browse/CALCITE-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6453:
Labels: pull-request-available (was: )
> Simplify casts which are result of constant reduction
> -
>
> Key: CALCITE-6453
> URL: https://issues.apache.org/jira/browse/CALCITE-6453
> Project: Calcite
> Issue Type: Improvement
>Reporter: Krisztian Kasa
>Assignee: Krisztian Kasa
>Priority: Major
> Labels: pull-request-available
>
> RexSimplify transforms nullable cast expressions with a non-nullable literal
> operand which type is different from the cast type to another cast expression
> with a literal operand with the same type as the cast.
> If simplify is called again using the result cast expression of the first
> simplification we get a literal only as a result.
> Example:
> Initial expression
> {code:java}
> CAST(_UTF-16LE'2020-10-30':VARCHAR(2147483647) CHARACTER SET "UTF-16LE"):DATE
> {code}
> where the operand is non-nullable varchar and the result of the cast is
> nullable date.
> After the first simplify call we get
> {code:java}
> CAST(2020-10-30:DATE):DATE
> {code}
> where the operand type is non-nullable date and the cast type is nullable
> date.
> https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L2269-L2276
> After the second simplify call we get
> {code:java}
> 2020-10-30:DATE
> {code}
> where the literal type is non-nullable date
> https://github.com/apache/calcite/blob/8ab0b03326730aa2cc6b476b2cbd8f99799bdacb/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L2195-L2196
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-4921) Nested NATURAL JOINs or JOINs with USING can't find common column
[
https://issues.apache.org/jira/browse/CALCITE-4921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-4921:
Labels: pull-request-available (was: )
> Nested NATURAL JOINs or JOINs with USING can't find common column
> -
>
> Key: CALCITE-4921
> URL: https://issues.apache.org/jira/browse/CALCITE-4921
> Project: Calcite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: pull-request-available
>
> {{SqlValidatorUtil#deriveNaturalJoinColumnList}} can't correctly derive
> common columns for JOIN if the left hand of it is another NATURAL JOIN or
> JOIN with USING. For example:
> {noformat}
> SELECT * FROM (values (1, 1)) as t1(a, b)
> NATURAL JOIN (values (1, 1)) as t2(a, c)
> NATURAL JOIN (values (1, 1)) as t3(a, d){noformat}
> Builds incorrect plan:
> {noformat}
> LogicalProject(A=[$0], B=[$1], C=[$3], A1=[$4], D=[$5])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalJoin(condition=[=($0, $2)], joinType=[inner])
> LogicalValues(tuples=[[{ 1, 1 }]])
> LogicalValues(tuples=[[{ 1, 1 }]])
> LogicalValues(tuples=[[{ 1, 1 }]]){noformat}
> Queries with USING also have problems:
> {noformat}
> SELECT * FROM (values (1, 1)) as t1(a, b)
> JOIN (values (1, 1)) as t2(a, c) USING (a)
> JOIN (values (1, 1)) as t3(a, d) USING (a){noformat}
> Fails with:
> {noformat}
> Column name 'A' in USING clause is not unique on one side of join{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6312) Add LOG function (enabled in PostgreSQL library)
[ https://issues.apache.org/jira/browse/CALCITE-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6312: Labels: pull-request-available (was: ) > Add LOG function (enabled in PostgreSQL library) > > > Key: CALCITE-6312 > URL: https://issues.apache.org/jira/browse/CALCITE-6312 > Project: Calcite > Issue Type: Sub-task >Reporter: James Duong >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > > * We have the BigQuery implementation which has a 1-arg overload that uses > base e (ln), and a 2-arg overload which is LOG(value, base) > * PostgreSQL's 1-arg version uses base 10 and the 2-arg overload has the > order reversed – LOG(base, value) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6449) Enable PostgreSQL implementations of to_date/to_timestamp
[
https://issues.apache.org/jira/browse/CALCITE-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6449:
Labels: pull-request-available (was: )
> Enable PostgreSQL implementations of to_date/to_timestamp
> -
>
> Key: CALCITE-6449
> URL: https://issues.apache.org/jira/browse/CALCITE-6449
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Reporter: Norman Jordan
>Assignee: Norman Jordan
>Priority: Minor
> Labels: pull-request-available
>
> Update the PostgreSQL function library to use PostgreSQL specific
> implementations for *TO_DATE* and {*}TO_TIMESTAMP{*}. These implementations
> should fully support the date/time formatting patterns that PostgreSQL
> supports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6447) extract common expressions for disjunctions in Join
[
https://issues.apache.org/jira/browse/CALCITE-6447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6447:
Labels: pull-request-available (was: )
> extract common expressions for disjunctions in Join
> ---
>
> Key: CALCITE-6447
> URL: https://issues.apache.org/jira/browse/CALCITE-6447
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.37.0
>Reporter: ruanhui
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> For SQL:
> {code:java}
> select *
> from tbl_a
> join tbl_b on tbl_a.id = tbl_b.id
> where (tbl_a.x > 100 and tbl_b.y < 10)
>or (tbl_a.x > 100 and tbl_b.z > 20){code}
> we can rewrite it to
> {code:java}
> select *
> from tbl_a
> join tbl_b on tbl_a.id = tbl_b.id
> where tbl_a.x > 100
> and (tbl_b.y < 10 or tbl_b.z > 20){code}
> And in this way *tbl_a.x > 100* can be pushed down and it is likely that this
> will help reduce the amount of data involved in the join.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6444) Add an Amazon Redshift SqlLibrary
[ https://issues.apache.org/jira/browse/CALCITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6444: Labels: pull-request-available (was: ) > Add an Amazon Redshift SqlLibrary > -- > > Key: CALCITE-6444 > URL: https://issues.apache.org/jira/browse/CALCITE-6444 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0 >Reporter: Norman Jordan >Assignee: Norman Jordan >Priority: Major > Labels: pull-request-available > > The Babel tests assume that RedShift is a union of the Oracle and PostgreSQL > libraries. This is not accurate. There are functions such as *INCR* that are > supported by Oracle and not by RedShift. Problems will also occur when Oracle > and Postgres both support a function of the same name that needs different > implementations. > [https://github.com/apache/calcite/blob/main/babel/src/test/java/org/apache/calcite/test/BabelQuidemTest.java#L110] -- This message was sent by Atlassian Jira (v8.20.10#820010)
