[jira] [Commented] (CALCITE-6184) Add checkNullTest on SqlOperatorTest
[ https://issues.apache.org/jira/browse/CALCITE-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804613#comment-17804613 ] hongyu guo commented on CALCITE-6184: - Fixed in [https://github.com/apache/calcite/commit/294e42f0fb30963dcb452f4f3b5ed1627a47a296] [~caicancai] , thanks for your contribution! > Add checkNullTest on SqlOperatorTest > > > Key: CALCITE-6184 > URL: https://issues.apache.org/jira/browse/CALCITE-6184 > Project: Calcite > Issue Type: Test > Components: tests >Affects Versions: 1.36.0 >Reporter: Caican Cai >Assignee: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Some tests in calcite's SqlOperatorTest lack checknull. I think the checknull > test should be added. > 1. Conducive to the learning of new developers > 2. Based on the checknull test, we may be able to find some bugs in calcite’s > sqoperator. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (CALCITE-6185) Support more date format
[ https://issues.apache.org/jira/browse/CALCITE-6185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caican Cai closed CALCITE-6185. --- Resolution: Incomplete > Support more date format > > > Key: CALCITE-6185 > URL: https://issues.apache.org/jira/browse/CALCITE-6185 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.36.0 >Reporter: Caican Cai >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > There are currently some date formats that are not supported. More postgres > and bigquery date formats are supported. > # Support CC format format and add tests (pg) > # Consider supporting timezone, > # full lower case day name(day) pg > # lower case day name(dy) pg > [https://cloud.google.com/bigquery/docs/reference/standard-sql/format-elements] > [https://www.postgresql.org/docs/current/functions-formatting.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6190) Incorrect precision derivation for negative numeric types
[
https://issues.apache.org/jira/browse/CALCITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned CALCITE-6190:
---
Assignee: Evgeny Stanilovsky
> Incorrect precision derivation for negative numeric types
> -
>
> Key: CALCITE-6190
> URL: https://issues.apache.org/jira/browse/CALCITE-6190
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
>
> Test highlights the problem :
> {code:java}
> @Test void testTypeOfAs() {
> sql("select DECIMAL '100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> sql("select DECIMAL '-100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> }
> {code}
> Throws exception for second expression:
> {noformat}
> Expected: is "DECIMAL(5, 2) NOT NULL"
> but: was "DECIMAL(6, 2) NOT NULL"
> {noformat}
> Seems root cause in SqlLiteral#createExactNumeric precision derivation not
> consider negative numbers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6190) Incorrect precision derivation for negative numeric types
[
https://issues.apache.org/jira/browse/CALCITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned CALCITE-6190:
---
Assignee: Mihai Budiu (was: Evgeny Stanilovsky)
> Incorrect precision derivation for negative numeric types
> -
>
> Key: CALCITE-6190
> URL: https://issues.apache.org/jira/browse/CALCITE-6190
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Mihai Budiu
>Priority: Major
>
> Test highlights the problem :
> {code:java}
> @Test void testTypeOfAs() {
> sql("select DECIMAL '100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> sql("select DECIMAL '-100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> }
> {code}
> Throws exception for second expression:
> {noformat}
> Expected: is "DECIMAL(5, 2) NOT NULL"
> but: was "DECIMAL(6, 2) NOT NULL"
> {noformat}
> Seems root cause in SqlLiteral#createExactNumeric precision derivation not
> consider negative numbers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6172) Allow aliased operators to re-use existing tests
[ https://issues.apache.org/jira/browse/CALCITE-6172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanner Clary resolved CALCITE-6172. --- Fix Version/s: 1.37.0 Resolution: Fixed Merged via [ee4cb35|https://github.com/apache/calcite/commit/ee4cb3581cfa346a5dab40cc5b53a1571b6191a4], thanks to [~julianhyde] and [~Sergey Nuyanzin] for both their reviews and contributions to this commit! > Allow aliased operators to re-use existing tests > > > Key: CALCITE-6172 > URL: https://issues.apache.org/jira/browse/CALCITE-6172 > Project: Calcite > Issue Type: Improvement >Reporter: Tanner Clary >Assignee: Tanner Clary >Priority: Major > Labels: pull-request-available > Fix For: 1.37.0 > > > Currently, for operators that have multiple names (potentially across > multiple libraries), there is no convenient way to re-use tests other than > just copy and pasting. To avoid redundancy and potential discrepancies, it > would be helpful if the same set of tests could be used for each alias. > I'll modify this case once I have some ideas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
[
https://issues.apache.org/jira/browse/CALCITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804581#comment-17804581
]
Evgeny Stanilovsky commented on CALCITE-6192:
-
[~mbudiu] thanks ! fix is ready for review
> DEFAULT expression with NULL value throws unexpected exception
> --
>
> Key: CALCITE-6192
> URL: https://issues.apache.org/jira/browse/CALCITE-6192
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> Processing of DEFAULT expression was improved in scope of [1] but seems there
> is one case with NULL as value is not covered and processed erroneously.
> {code:java}
> create table tdef1 (i int not null, col1 int default null);
> insert into tdef1(i, col1) values (1, DEFAULT);
> {code}
> throws :
> {code:java}
> Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
> class org.apache.calcite.sql.SqlLiteral: NULL
> {code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
[
https://issues.apache.org/jira/browse/CALCITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned CALCITE-6192:
---
Assignee: Evgeny Stanilovsky
> DEFAULT expression with NULL value throws unexpected exception
> --
>
> Key: CALCITE-6192
> URL: https://issues.apache.org/jira/browse/CALCITE-6192
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> Processing of DEFAULT expression was improved in scope of [1] but seems there
> is one case with NULL as value is not covered and processed erroneously.
> {code:java}
> create table tdef1 (i int not null, col1 int default null);
> insert into tdef1(i, col1) values (1, DEFAULT);
> {code}
> throws :
> {code:java}
> Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
> class org.apache.calcite.sql.SqlLiteral: NULL
> {code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
[
https://issues.apache.org/jira/browse/CALCITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6192:
Labels: pull-request-available (was: )
> DEFAULT expression with NULL value throws unexpected exception
> --
>
> Key: CALCITE-6192
> URL: https://issues.apache.org/jira/browse/CALCITE-6192
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> Processing of DEFAULT expression was improved in scope of [1] but seems there
> is one case with NULL as value is not covered and processed erroneously.
> {code:java}
> create table tdef1 (i int not null, col1 int default null);
> insert into tdef1(i, col1) values (1, DEFAULT);
> {code}
> throws :
> {code:java}
> Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
> class org.apache.calcite.sql.SqlLiteral: NULL
> {code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6188) Multi-query optimization
[
https://issues.apache.org/jira/browse/CALCITE-6188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804548#comment-17804548
]
Jay Narale commented on CALCITE-6188:
-
Makes sense, and I think we could reuse our scheduling dag logic in cases where
dependencies exist or if the user specifies any dependencies.
> Multi-query optimization
>
>
> Key: CALCITE-6188
> URL: https://issues.apache.org/jira/browse/CALCITE-6188
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Priority: Major
>
> Devise extensions to SQL so that queries with multiple input tables, multiple
> intermediate tables, and multiple output data sets (result sets and DML
> operations) can be defined in one SQL statement, optimized, and executed
> atomically.
> There are many flavors of multi-query optimization, depending on whether each
> occurrence of "multiple" in the previous paragraph is replaced with 0, 1 or
> "several". Our goal, here, is to allow them all to be expressed. We can then
> devise planning strategies that work for particular flavors.
> Examples of multi-queries:
> * {*}Multiple DML outputs{*}. An INSERT statement that writes into a table
> but also updates an index,
> * {*}Multiple DML outputs, complex intermediate tables{*}. A DAG that
> represents an ETL/ELT job;
> * {*}Multiple query outputs{*}. A query that produces several data sets (say
> a list of invoices for
> orders and a list of products that need to be restocked);
> * {*}DAG query{*}. A query that uses intermediate results more than once.
> See discussion in the [Multi-query optimization email
> thread|https://lists.apache.org/thread/mcdqwrtpx0os54t2nn9vtk17spkp5o5k].
> Here are some SQL examples.
> We add a new keyword {{MULTI}} that represents a statement whose output
> contains multiple data sets and DML operations, each with a unique name. For
> intermediate results, we use the existing {{WITH}} clause.
> h3. 1. Multi DML
> Read from one or more tables, write to one or more tables.
> An example is inserting into a table and also an index on that table
> (represented as a sorted table).
> {code:sql}
> WITH
> empDelta AS (
> SELECT * FROM emp2
> EXCEPT
> SELECT * FROM emp)
> MULTI
> insertEmp AS (
> INSERT INTO emp
> TABLE empDelta),
> insertEmpDeptno AS (
> MERGE empDeptno AS e
> USING TABLE empDelta AS d
> ON e.deptno = d.deptno
> WHEN NOT MATCHED THEN INSERT VALUES (deptno));
> {code}
> h3. 2. Query that creates temporary table and uses it more than once
> {code:sql}
> WITH
> temp AS (
> SELECT *
> FROM emp AS e
> JOIN dept USING (deptno)
> WHERE e.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> SELECT deptno,
> (SELECT AVG(sal)
> FROM temp AS t
> WHERE t.deptno = e.deptno) AS deptAvgSal,
> (SELECT AVG(sal)
> FROM temp AS t
> WHERE t.job = e.job) AS jobAvgSal
> FROM e
> WHERE e.deptno IN (10, 20);
> {code}
> h3. 3. Query whose optimal plan might use a temporary table
> This query produces the same result as the previous query. There is a common
> relational expression, so the optimizer should consider a DAG plan with a
> reified intermediate result.
> {code:sql}
> SELECT deptno,
> (SELECT AVG(e2.sal)
> FROM emp AS e2
> JOIN dept AS d USING (deptno)
> WHERE (e2.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> AND e2.deptno = e.deptno) AS deptAvgSal,
> (SELECT AVG(e3.sal)
> FROM emp AS e3
> JOIN dept AS d USING (deptno)
> WHERE (e3.job = 'MANAGER'
> OR d.location = 'CHICAGO')
> AND e3.job = e.job) AS jobAvgSal
> FROM e
> WHERE e.deptno IN (10, 20);
> {code}
> h3. 4. Query that produces several data sets
> {code:sql}
> WITH
> newOrders AS (
> SELECT *
> FROM orders
> WHERE orderDate > DATE '2023-01-25')
> MULTI
> invoices AS (
> SELECT customerName, SUM(amount)
> FROM newOrders
> GROUP BY customerName),
> restock AS (
> SELECT productId
> FROM inventory
> WHERE productId IN (
> SELECT productId FROM newOrders)
> AND itemsOnHand < 10);
> {code}
> h3. 5. Query with a complex DAG, multiple output data sets and one DML
> {code:sql}
> WITH
> t0 AS (
> SELECT * FROM t WHERE x > 5),
> t00 AS (
> SELECT * FROM t0 WHERE y < 10),
> t000 AS (
> SELECT x, MIN(y) FROM t00 GROUP BY x),
> t1 AS (
> SELECT * FROM t WHERE y > 3),
> t10 AS (
> SELECT * FROM t1 WHERE x < 8),
> t2 AS (
> SELECT * FROM t000
> INTERSECT
> SELECT * FROM t10),
> t3 AS (
> SELECT * FROM u
> INTERSECT
> SELECT * FROM t00)
> MULTI
> q0 AS (SELECT * FROM t3),
> q1 AS (SELECT * FROM t2),
> d0 AS (DELETE FROM v WHERE v.x IN (SELECT x FROM t1));
> {code}
> The data flow is the following DAG:
> {noformat}
> u +
>
[jira] [Resolved] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu resolved CALCITE-6194. -- Fix Version/s: 1.37.0 Resolution: Fixed Fixed by commit https://github.com/apache/calcite/commit/5920262929799df78f08b784627f3d2ccdc5e3c5 > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Trivial > Labels: pull-request-available > Fix For: 1.37.0 > > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6095) Arithmetic expression with VARBINARY value causes AssertionFailure
[
https://issues.apache.org/jira/browse/CALCITE-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6095.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in commit
https://github.com/apache/calcite/commit/1f6022b4d421bf9d237567f918e523680d75e6bb
> Arithmetic expression with VARBINARY value causes AssertionFailure
> --
>
> Key: CALCITE-6095
> URL: https://issues.apache.org/jira/browse/CALCITE-6095
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The following SqlOperatorTest causes an AssertionFailure:
> {code:java}
> f.check("SELECT x'31' + 0", "INTEGER NOT NULL", "50");
> {code}
> The top of the stack trace is:
> {code}
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.needToCast(AbstractTypeCoercion.java:297)
> at
> org.apache.calcite.sql.validate.implicit.AbstractTypeCoercion.coerceOperandType(AbstractTypeCoercion.java:117)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.binaryArithmeticWithStrings(TypeCoercionImpl.java:200)
> at
> org.apache.calcite.sql.validate.implicit.TypeCoercionImpl.binaryArithmeticCoercion(TypeCoercionImpl.java:172)
> at
> org.apache.calcite.sql.type.CompositeOperandTypeChecker.checkOperandTypes(CompositeOperandTypeChecker.java:261)
> at
> org.apache.calcite.sql.SqlOperator.checkOperandTypes(SqlOperator.java:761)
> at
> org.apache.calcite.sql.SqlOperator.validateOperands(SqlOperator.java:498)
> at org.apache.calcite.sql.SqlOperator.deriveType(SqlOperator.java:607)
> at
> org.apache.calcite.sql.SqlBinaryOperator.deriveType(SqlBinaryOperator.java:178)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
[
https://issues.apache.org/jira/browse/CALCITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6074.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in commit
https://github.com/apache/calcite/commit/08f685683e8e6e97b47189d95603af17051d
> The size of REAL, DOUBLE, and FLOAT is not consistent
> -
>
> Key: CALCITE-6074
> URL: https://issues.apache.org/jira/browse/CALCITE-6074
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> This stems from the review of CALCITE-6052
> Which one is 8 bytes and which one is 4 bytes?
> The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8
> bytes, (which is very weird for Java users), and REAL is 4 bytes.
> But an audit of the code shows that:
> In AggregateNode.maxMinClass:
> {code:java}
> case FLOAT:
> return max ? MaxFloat.class : MinFloat.class;
> case DOUBLE:
> case REAL:
> return max ? MaxDouble.class : MinDouble.class;
> {code}
> In VisitorDataContext:
> {code:java}
> case DOUBLE:
> return Pair.of(index, rexLiteral.getValueAs(Double.class));
> case REAL:
> return Pair.of(index, rexLiteral.getValueAs(Float.class));
> {code}
> (no case for FLOAT)
> In RelMdSize:
> {code:java}
>case FLOAT:
> case REAL:
>
> return 4d;
> {code}
> in RelDataTypeFactoryImpl:
> {code:java}
> case REAL:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case FLOAT:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case DOUBLE:
> // the default max precision is 19, so this is actually DECIMAL(19, 15)
> // but derived system can override the max precision/scale.
> return createSqlType(SqlTypeName.DECIMAL, 30, 15);
> {code}
> The reference.md itself seems to be wrong:
> {code}
> | REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
> | DOUBLE | 8 byte floating point | 15 decimal digits precision.
> {code}
> and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6002) CONTAINS_SUBSTR does not unparse correctly
[ https://issues.apache.org/jira/browse/CALCITE-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804532#comment-17804532 ] Mihai Budiu commented on CALCITE-6002: -- [~tanclary] The bug arises because the CONTAINS_SUBSTR is an instance of SqlBasicFunction, which is always unparsed in a standard way. However, a custom class should be defined to unparse the json_scope argument in a special way. Note that there is already a disabled test for this case in SqlOperatorUnparseTest. > CONTAINS_SUBSTR does not unparse correctly > -- > > Key: CALCITE-6002 > URL: https://issues.apache.org/jira/browse/CALCITE-6002 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Mihai Budiu >Assignee: Tanner Clary >Priority: Minor > > There are in fact two bugs related to CONTAINS_SUBSTR. > The first one is that the documentation does not render in the md file, there > must be something wrong with the html escape sequences. > The second one is that it does not unparse into a correct form. > [~tanclary] I think you added this code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because of wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6193:
-
Fix Version/s: 1.37.0
> SubstitutionVisitor stop trying incorrect subtree because of wrong parent
> relationship when replace query
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, thus the incorrect parent relationship
> may occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5448) ReduceExpressionsRule does not always constant fold expressions
[
https://issues.apache.org/jira/browse/CALCITE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804529#comment-17804529
]
Mihai Budiu commented on CALCITE-5448:
--
I will close this issue, since there are workarounds.
It is a code usability problem, though, but I am not sure about the right fix.
> ReduceExpressionsRule does not always constant fold expressions
>
>
> Key: CALCITE-5448
> URL: https://issues.apache.org/jira/browse/CALCITE-5448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> I have manually built a HepPlanner to optimize the SQL queries, and I
> discovered that the rule ReduceExpressionsRule does not really do anything in
> my setup.
> I am looking at method ReduceExpressionsRule.reduceExpressionsInternal.
> There is this piece of code:
> {code}
> RexExecutor executor = rel.getCluster().getPlanner().getExecutor();
> if (executor == null) {
> // Cannot reduce expressions: caller has not set an executor in their
> // environment. Caller should execute something like the following
> before
> // invoking the planner:
> //
> // final RexExecutorImpl executor =
> // new RexExecutorImpl(Schemas.createDataContext(null));
> // rootRel.getCluster().getPlanner().setExecutor(executor);
> return changed;
> }
> {code}
>
> However, the caller of this function, the method reduceExpressions, has
> carefully inserted an executor in the RexSimplify class in case the cluster
> has no executor. Shouldn't that executor be used instead of trying the
> missing one? (It is currently private in the RexSimplify class.)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5448) ReduceExpressionsRule does not always constant fold expressions
[
https://issues.apache.org/jira/browse/CALCITE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-5448.
--
Resolution: Workaround
> ReduceExpressionsRule does not always constant fold expressions
>
>
> Key: CALCITE-5448
> URL: https://issues.apache.org/jira/browse/CALCITE-5448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> I have manually built a HepPlanner to optimize the SQL queries, and I
> discovered that the rule ReduceExpressionsRule does not really do anything in
> my setup.
> I am looking at method ReduceExpressionsRule.reduceExpressionsInternal.
> There is this piece of code:
> {code}
> RexExecutor executor = rel.getCluster().getPlanner().getExecutor();
> if (executor == null) {
> // Cannot reduce expressions: caller has not set an executor in their
> // environment. Caller should execute something like the following
> before
> // invoking the planner:
> //
> // final RexExecutorImpl executor =
> // new RexExecutorImpl(Schemas.createDataContext(null));
> // rootRel.getCluster().getPlanner().setExecutor(executor);
> return changed;
> }
> {code}
>
> However, the caller of this function, the method reduceExpressions, has
> carefully inserted an executor in the RexSimplify class in case the cluster
> has no executor. Shouldn't that executor be used instead of trying the
> missing one? (It is currently private in the RexSimplify class.)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because of wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804528#comment-17804528
]
Julian Hyde commented on CALCITE-6193:
--
This bug looks legitimate. However, it would be useful if you can characterize
which kinds of materialized view suffer from this problem. Our users reading
the release notes may not be familiar with SubstitutionVisitor.
> SubstitutionVisitor stop trying incorrect subtree because of wrong parent
> relationship when replace query
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, thus the incorrect parent relationship
> may occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6105) Documentation does not specify the behavior of SPLIT function for empty string arguments
[ https://issues.apache.org/jira/browse/CALCITE-6105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu resolved CALCITE-6105. -- Fix Version/s: 1.37.0 Resolution: Fixed Fixed in commit https://github.com/apache/calcite/commit/7049f9a33501c199fe04b589dd067adcae9f1ee7 > Documentation does not specify the behavior of SPLIT function for empty > string arguments > > > Key: CALCITE-6105 > URL: https://issues.apache.org/jira/browse/CALCITE-6105 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > Various string libraries choose different behaviors for SPLIT when the first > or the second arguments are empty strings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6029) SqlOperatorTest cannot test operators that require the Babel parser
[
https://issues.apache.org/jira/browse/CALCITE-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6029.
--
Resolution: Workaround
I have closed the associated PR as well.
> SqlOperatorTest cannot test operators that require the Babel parser
> ---
>
> Key: CALCITE-6029
> URL: https://issues.apache.org/jira/browse/CALCITE-6029
> Project: Calcite
> Issue Type: Bug
> Components: babel, core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> In SqlOperatorTest one can write code like this:
> {code:java}
> @Test void testDatePart() {
> final SqlOperatorFixture f = fixture().withLibrary(SqlLibrary.POSTGRESQL)
> .withParserConfig(p ->
> p.withParserFactory(SqlBabelParserImpl.FACTORY));
> {code}
> This almost works, but the SqlOperatorTest.check function makes a connection
> ignores the parserFactory, so parsing will fail:
> {code:java}
> @Override public void check(SqlTestFactory factory, String query,
> SqlTester.TypeChecker typeChecker,
> SqlTester.ParameterChecker parameterChecker,
> SqlTester.ResultChecker resultChecker) {
> super.check(factory, query, typeChecker, parameterChecker,
> resultChecker);
> final RelDataTypeSystem typeSystem =
> factory.typeSystemTransform.apply(RelDataTypeSystem.DEFAULT);
> final ConnectionFactory connectionFactory =
> factory.connectionFactory
> .with(CalciteConnectionProperty.TYPE_SYSTEM, uri(FIELD)); ///
> NO PARSER_FACTORY HERE
> {code}
> I am trying to fix this by adding a PARSER_FACTORY argument to the
> connection, but then I get a class loader error from
> AvaticaUtils.instantiatePlugin, which, in this case, cannot find the
> SqlBabelParserImpl#FACTORY in the classpath.
> I would appreciate some help solving this last bit.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5986) The typeFamily property of SqlTypeName is used inconsistently
[
https://issues.apache.org/jira/browse/CALCITE-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu closed CALCITE-5986.
Resolution: Workaround
The issue is real, but fixing it would be too disruptive.
> The typeFamily property of SqlTypeName is used inconsistently
> -
>
> Key: CALCITE-5986
> URL: https://issues.apache.org/jira/browse/CALCITE-5986
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
>
> In SqlTypeFamily we have this code:
> {code:java}
> private static final Map JDBC_TYPE_TO_FAMILY =
> ...
> .put(Types.FLOAT, NUMERIC)
> .put(Types.REAL, NUMERIC)
> .put(Types.DOUBLE, NUMERIC)
> {code}
> But it looks to me like the type family should be APPROXIMATE_NUMERIC.
> This impacts the way RelToSqlConverter works, for instance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804519#comment-17804519 ] Julian Hyde commented on CALCITE-6194: -- Practice has changed recently. Can you change "and also thank the contributor for their contribution" to "and also thank the contributor for their contribution (if they are not a committer)". > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Trivial > Labels: pull-request-available > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-6194: Labels: pull-request-available (was: ) > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Trivial > Labels: pull-request-available > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihai Budiu reassigned CALCITE-6194: Assignee: Mihai Budiu > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Trivial > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804504#comment-17804504 ] Mihai Budiu commented on CALCITE-6194: -- I used the PR links in my messages. > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Trivial > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
[ https://issues.apache.org/jira/browse/CALCITE-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804502#comment-17804502 ] Tanner Clary commented on CALCITE-6194: --- I guess it doesn't explicitly say the main branch but I'm not sure what else would make sense? > Contributor rules do not give instructions about how to quote commits > - > > Key: CALCITE-6194 > URL: https://issues.apache.org/jira/browse/CALCITE-6194 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.36.0 >Reporter: Mihai Budiu >Priority: Trivial > > https://calcite.apache.org/docs/howto.html#merging-pull-requests > According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed > the commit that is quoted in the JIRA case has to be with respect to the main > branch of Calcite. The instructions for committers do not specify this > information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5130) AssertionError: "Conversion to relational algebra failed to preserve datatypes" when union VARCHAR literal and CAST(null AS INTEGER)
[
https://issues.apache.org/jira/browse/CALCITE-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804501#comment-17804501
]
Mihai Budiu commented on CALCITE-5130:
--
Fixed in commit
https://github.com/apache/calcite/commit/11c540686a47765f8c6232058ec9eb1f418e4efa
> AssertionError: "Conversion to relational algebra failed to preserve
> datatypes" when union VARCHAR literal and CAST(null AS INTEGER)
> -
>
> Key: CALCITE-5130
> URL: https://issues.apache.org/jira/browse/CALCITE-5130
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.31.0
>Reporter: Yingyu Wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 0: jdbc:calcite:model=src/test/resources/mode> select CAST(null AS INTEGER)
> union select '10';
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR NOT NULL EXPR$0) NOT NULL
> converted type:
> RecordType(VARCHAR EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[false])
> LogicalValues(tuples=[[\{ null }]])
> LogicalValues(tuples=[[\{ '10' }]])
>
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:487)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:602)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:257)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:648)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:674)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
> at sqlline.Commands.executeSingleQuery(Commands.java:1130)
> at sqlline.Commands.execute(Commands.java:1079)
> at sqlline.Commands.sql(Commands.java:1033)
> at sqlline.SqlLine.dispatch(SqlLine.java:822)
> at sqlline.SqlLine.begin(SqlLine.java:596)
> at sqlline.SqlLine.start(SqlLine.java:269)
> at sqlline.SqlLine.main(SqlLine.java:208)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6149) ClickHouseSqlDialect should support cast to Nullable
[
https://issues.apache.org/jira/browse/CALCITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804500#comment-17804500
]
Mihai Budiu commented on CALCITE-6149:
--
Fixed by commit
https://github.com/apache/calcite/commit/7b97c4e4581094cc405d0f0fa4c16f462ef1166d
> ClickHouseSqlDialect should support cast to Nullable
>
>
> Key: CALCITE-6149
> URL: https://issues.apache.org/jira/browse/CALCITE-6149
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: ChenLuyang
>Priority: Minor
> Labels: dialect, pull-request-available
> Fix For: 1.37.0
>
>
> In ClickHouse, there is an issue with RelDataType of Nullable type when
> casting to a non-Nullable type. For example, {{SELECT CAST(NULL, 'Int32')}}
> will throw an error. In such cases, we should use {{SELECT CAST(NULL,
> 'Nullable(Int32)')}} instead.
>
> related error messages.
> DB::Exception: Cannot convert NULL value to non-Nullable type
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6194) Contributor rules do not give instructions about how to quote commits
Mihai Budiu created CALCITE-6194: Summary: Contributor rules do not give instructions about how to quote commits Key: CALCITE-6194 URL: https://issues.apache.org/jira/browse/CALCITE-6194 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.36.0 Reporter: Mihai Budiu https://calcite.apache.org/docs/howto.html#merging-pull-requests According to [~jhyde] (in a comment on [CALCITE-6178] when an issue is closed the commit that is quoted in the JIRA case has to be with respect to the main branch of Calcite. The instructions for committers do not specify this information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804496#comment-17804496
]
Julian Hyde commented on CALCITE-6178:
--
(In my view, PRs are just scaffolding. Jira and the git main branch are the
permanent artifacts.)
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804494#comment-17804494
]
Julian Hyde commented on CALCITE-6178:
--
Still not good. 6d95a10 isn't on main. You must use a URL starting with
{{github.com/apache/calcite/commit}}, like this:
Fixed in
[22b424e5|https://github.com/apache/calcite/commit/22b424e5f2084dd1c352ddeb752a8fd8bfa288b0].
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804493#comment-17804493
]
Mihai Budiu commented on CALCITE-6178:
--
Fixed by commit
https://github.com/apache/calcite/pull/3598/commits/6d95a10ada58dfa34ad9d86b5b5956afd96ce60e
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804490#comment-17804490
]
Julian Hyde commented on CALCITE-6178:
--
[~mbudiu], Can you note the actual commit SHA (in main branch) not the PR.
Sometimes what is committed is not identical to the PR.
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6190) Incorrect precision derivation for negative numeric types
[
https://issues.apache.org/jira/browse/CALCITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804486#comment-17804486
]
Mihai Budiu commented on CALCITE-6190:
--
If you plan to provide a fix perhaps you can assign this task to yourself.
Otherwise I can work on it - and then please assign it to me.
> Incorrect precision derivation for negative numeric types
> -
>
> Key: CALCITE-6190
> URL: https://issues.apache.org/jira/browse/CALCITE-6190
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
>
> Test highlights the problem :
> {code:java}
> @Test void testTypeOfAs() {
> sql("select DECIMAL '100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> sql("select DECIMAL '-100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> }
> {code}
> Throws exception for second expression:
> {noformat}
> Expected: is "DECIMAL(5, 2) NOT NULL"
> but: was "DECIMAL(6, 2) NOT NULL"
> {noformat}
> Seems root cause in SqlLiteral#createExactNumeric precision derivation not
> consider negative numbers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6176) 'exists' in 'join on' has a wrong result with CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
[
https://issues.apache.org/jira/browse/CALCITE-6176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804451#comment-17804451
]
Egor Malko commented on CALCITE-6176:
-
I have done small investigation. It seems like
{{org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteExists()}}
method is a problem. It was added in CALCITE-2329 with intention to optimize
cases like
{code:sql}
select sal from emp where EXISTS (select deptno from dept where deptno=2)
{code}
Only optimization in {{rewriteExists()}} expects right table not to be used
after the join and changes it freely, but it's not true in the current issue
cases.
Also
[CALCITE-2329|https://github.com/apache/calcite/commit/1ae6a52603006741a4cb6bf558c58d9ac08e866a#diff-a57af2470b3215be0ce7d94a226f1997d9417c613fd7f32097fd07543b30633a]
[
PR|https://github.com/apache/calcite/commit/1ae6a52603006741a4cb6bf558c58d9ac08e866a#diff-a57af2470b3215be0ce7d94a226f1997d9417c613fd7f32097fd07543b30633a]
contains suspicious changes. Before PR, EXISTS cases were processed with IN
ones, and after they started to be processed in the own {{rewriteExists()}}
method with only one optimization from the issue. So are we possibly got rid
from old optimizations?
Please, validate my thoughts, because I'm new to the project
> 'exists' in 'join on' has a wrong result with
> CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
> ---
>
> Key: CALCITE-6176
> URL: https://issues.apache.org/jira/browse/CALCITE-6176
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: SimonAlexs
>Priority: Critical
>
> In calcite 1.36.0, using flowing rules:
> CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
> CoreRules.JOIN_CONDITION_PUSH
> I tested some wrong cases(the expected result and actual result are in
> comment):
> * expected result: the result in mysql;
> * actual result: the result in calcite1.36.0
> {code:java}
> -- not exists, expected: 1, 2
> --actual: 1, null
> select *
> from (select 1 id) t1
> left join (select 2 id) t2
> on not exists(select *
> from (select 3 id) p
> where p.id=t2.id)
> -- or exists, expected: 1, null
> -- actual: 1, 2
> select *
> from (select 1 id) t1
> left join (select 2 id) t2
> on t1.id=t2.id or exists(select *
>from (select 3 id) p
>where p.id=t2.id)
> -- or not exists, expected: 1, 2
> -- actual: 1, null
> select *
> from (select 1 id) t1
> left join (select 2 id) t2
> on t1.id=t2.id or not exists(select *
>from (select 3 id) p
>where p.id=t2.id)
> -- and not exists, expected: 1, null
> -- 2, 2
> -- actual: 1, null
> -- 2, null
> select *
> from (select 1 id
> union all
> select 2) t1
> left join (select 2 id) t2
> on t1.id=t2.id and not exists(select *
> from (select 3 id) p
> where p.id=t1.id){code}
> This seems a bug.
> The rel of case 2 is as below. The reason I guess is that, The '$1' in 'IS
> NOT NULL($1)' of line 3 may be wrong.Because In the rel, the $1 represents
> the first column of the right table, which is usually not null depends on
> right input data. However, it should represent the column name 'i' in right
> table which means the 'exists' result.
> This is only my guessing.The real reason for this is needed to find by users
> who really understand Calcite.
> LogicalProject(id=[$0], id0=[$1])
> LogicalProject(id=[$0], id0=[$1])
> LogicalJoin(condition=[OR(=($0, $1), IS NOT NULL($1))], joinType=[left])
> LogicalValues(tuples=[[\{1}]])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[\{1}])
> LogicalValues(tuples=[[\{2}]])
> LogicalProject(i=[true])
> LogicalFilter(condition=[=($0, $cor0.id0)])
> LogicalValues(tuples=[[\{3}]])
> My whole code is:
> {code:java}
>
> Properties properties = new Properties();
> properties.put(CalciteConnectionProperty.MODEL.camelName(), "inline:");
> Connection calciteConnection = DriverManager.getConnection("jdbc:calcite:",
> properties);
> Statement calciteStatement = calciteConnection.createStatement();
> CalcitePrepare.Context prepareContext =
> calciteStatement.unwrap(CalciteServerStatement.class).createPrepareContext();
> CalciteSchema pSpaceSchema =
> prepareContext.getRootSchema().getSubSchema("ps", false);
> final FrameworkConfig config = Frameworks.newConfigBuilder()
>
[jira] [Commented] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
[
https://issues.apache.org/jira/browse/CALCITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804440#comment-17804440
]
Mihai Budiu commented on CALCITE-6192:
--
Actually, our case is slightly different, so perhaps my fix would not apply,
but this is still related.
> DEFAULT expression with NULL value throws unexpected exception
> --
>
> Key: CALCITE-6192
> URL: https://issues.apache.org/jira/browse/CALCITE-6192
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
>
> Processing of DEFAULT expression was improved in scope of [1] but seems there
> is one case with NULL as value is not covered and processed erroneously.
> {code:java}
> create table tdef1 (i int not null, col1 int default null);
> insert into tdef1(i, col1) values (1, DEFAULT);
> {code}
> throws :
> {code:java}
> Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
> class org.apache.calcite.sql.SqlLiteral: NULL
> {code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
[
https://issues.apache.org/jira/browse/CALCITE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804439#comment-17804439
]
Mihai Budiu commented on CALCITE-6192:
--
This is related to https://issues.apache.org/jira/browse/CALCITE-6129
I actually have a fix for this which I can submit.
> DEFAULT expression with NULL value throws unexpected exception
> --
>
> Key: CALCITE-6192
> URL: https://issues.apache.org/jira/browse/CALCITE-6192
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
>
> Processing of DEFAULT expression was improved in scope of [1] but seems there
> is one case with NULL as value is not covered and processed erroneously.
> {code:java}
> create table tdef1 (i int not null, col1 int default null);
> insert into tdef1(i, col1) values (1, DEFAULT);
> {code}
> throws :
> {code:java}
> Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
> class org.apache.calcite.sql.SqlLiteral: NULL
> {code}
> [1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6149) ClickHouseSqlDialect should support cast to Nullable
[
https://issues.apache.org/jira/browse/CALCITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6149.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Closed in https://github.com/apache/calcite/pull/3556
Thank you, [~chen768959]
> ClickHouseSqlDialect should support cast to Nullable
>
>
> Key: CALCITE-6149
> URL: https://issues.apache.org/jira/browse/CALCITE-6149
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: ChenLuyang
>Priority: Minor
> Labels: dialect, pull-request-available
> Fix For: 1.37.0
>
>
> In ClickHouse, there is an issue with RelDataType of Nullable type when
> casting to a non-Nullable type. For example, {{SELECT CAST(NULL, 'Int32')}}
> will throw an error. In such cases, we should use {{SELECT CAST(NULL,
> 'Nullable(Int32)')}} instead.
>
> related error messages.
> DB::Exception: Cannot convert NULL value to non-Nullable type
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804429#comment-17804429
]
Hanumath Rao Maduri commented on CALCITE-6178:
--
[~julianhyde] This
[PR|https://github.com/apache/calcite/commit/22b424e5f2084dd1c352ddeb752a8fd8bfa288b0]
was already merged. I can take care of the suggestion in an other commit.
[~mbudiu] Can you please close the Jira as FIXED.
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804429#comment-17804429
]
Hanumath Rao Maduri edited comment on CALCITE-6178 at 1/8/24 7:06 PM:
--
[~julianhyde] This
[PR|https://github.com/apache/calcite/commit/22b424e5f2084dd1c352ddeb752a8fd8bfa288b0]
was already merged. I can take care of the suggestion in an other commit.
[~mbudiu] -Can you please close the Jira as FIXED.-
was (Author: hanu.ncr):
[~julianhyde] This
[PR|https://github.com/apache/calcite/commit/22b424e5f2084dd1c352ddeb752a8fd8bfa288b0]
was already merged. I can take care of the suggestion in an other commit.
[~mbudiu] Can you please close the Jira as FIXED.
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5130) AssertionError: "Conversion to relational algebra failed to preserve datatypes" when union VARCHAR literal and CAST(null AS INTEGER)
[
https://issues.apache.org/jira/browse/CALCITE-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-5130.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in https://github.com/apache/calcite/pull/2803
Thank you, [~yingyu]
> AssertionError: "Conversion to relational algebra failed to preserve
> datatypes" when union VARCHAR literal and CAST(null AS INTEGER)
> -
>
> Key: CALCITE-5130
> URL: https://issues.apache.org/jira/browse/CALCITE-5130
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.31.0
>Reporter: Yingyu Wang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 0: jdbc:calcite:model=src/test/resources/mode> select CAST(null AS INTEGER)
> union select '10';
> java.lang.AssertionError: Conversion to relational algebra failed to preserve
> datatypes:
> validated type:
> RecordType(VARCHAR NOT NULL EXPR$0) NOT NULL
> converted type:
> RecordType(VARCHAR EXPR$0) NOT NULL
> rel:
> LogicalUnion(all=[false])
> LogicalValues(tuples=[[\{ null }]])
> LogicalValues(tuples=[[\{ '10' }]])
>
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:487)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:602)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:257)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:648)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:514)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:484)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:234)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:674)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:217)
> at sqlline.Commands.executeSingleQuery(Commands.java:1130)
> at sqlline.Commands.execute(Commands.java:1079)
> at sqlline.Commands.sql(Commands.java:1033)
> at sqlline.SqlLine.dispatch(SqlLine.java:822)
> at sqlline.SqlLine.begin(SqlLine.java:596)
> at sqlline.SqlLine.start(SqlLine.java:269)
> at sqlline.SqlLine.main(SqlLine.java:208)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6178.
--
Resolution: Fixed
Fixed in https://github.com/apache/calcite/pull/3598
Thank you [~hanu.ncr]
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6178:
-
Summary: WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE
property (was: WITH RECURSIVE query when cloned using SqlShuttle looses
RECURSIVE property)
> WITH RECURSIVE query when cloned using SqlShuttle loses RECURSIVE property
> --
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6178) WITH RECURSIVE query when cloned using SqlShuttle looses RECURSIVE property
[
https://issues.apache.org/jira/browse/CALCITE-6178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hanumath Rao Maduri updated CALCITE-6178:
-
Summary: WITH RECURSIVE query when cloned using SqlShuttle looses RECURSIVE
property (was: WITH RECURSIVE query when cloned using sqlshuttle looses
RECURSIVE property)
> WITH RECURSIVE query when cloned using SqlShuttle looses RECURSIVE property
> ---
>
> Key: CALCITE-6178
> URL: https://issues.apache.org/jira/browse/CALCITE-6178
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Hanumath Rao Maduri
>Assignee: Hanumath Rao Maduri
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Here is a test case which shows that a recursive query becomes a non
> recursive query when cloned using SqlShuttle.
> Copy paste the below test case in SqlParserTest
> {code:java}
> @Test void testRecursiveQueryCloned() throws Exception {
> SqlNode sqlNode = sql("with RECURSIVE emp2 as "
> + "(select * from emp union select * from emp2) select * from
> emp2").parser().parseStmt();
> SqlNode sqlNode1 = sqlNode.accept(new SqlShuttle() {
>@Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
>}
> });
> System.out.println(sqlNode1.toSqlString(c ->
> c.withAlwaysUseParentheses(false)).getSql());
> }{code}
> The above test case generates following output.
> {code:java}
> WITH "EMP2" AS (SELECT *
> FROM "EMP"
> UNION
> SELECT *
> FROM "EMP2") SELECT *
> FROM "EMP2"{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because of wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6193:
Labels: pull-request-available (was: )
> SubstitutionVisitor stop trying incorrect subtree because of wrong parent
> relationship when replace query
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, thus the incorrect parent relationship
> may occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because of wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mou Wu updated CALCITE-6193:
Description:
{code:java}
@Test void testStopTryIncorrectSubtree() {
final String mv = ""
+ "select \"empid\", \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"empid\", \"deptno\"";
final String query = ""
+ "select t1.\"deptno\"\n"
+ "from (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "union all\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t1 inner join (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
sql(mv, query)
.checkingThatResultContains(""
+ "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
+ " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
+ "LogicalUnion(all=[true])\n"
+ " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
+ "LogicalTableScan(table=[[hr, emps]])\n"
+ " LogicalAggregate(group=[{1}])\n"
+ "EnumerableTableScan(table=[[hr, MV0]])\n"
+ "LogicalAggregate(group=[{1}])\n"
+ " EnumerableTableScan(table=[[hr, MV0]])"
).ok();
}{code}
The test case above will fail because the second mv0 not be matched.
The root cause is that SubstitutionVisitor replace child nodes with
targetDescendant node itself, not a deep-copy replica, so they may share the
same node and the same parent node, thus the incorrect parent relationship may
occur, it will make stopTrying be wrong.
was:
{code:java}
@Test void testStopTryIncorrectSubtree() {
final String mv = ""
+ "select \"empid\", \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"empid\", \"deptno\"";
final String query = ""
+ "select t1.\"deptno\"\n"
+ "from (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "union all\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t1 inner join (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
sql(mv, query)
.checkingThatResultContains(""
+ "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
+ " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
+ "LogicalUnion(all=[true])\n"
+ " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
+ "LogicalTableScan(table=[[hr, emps]])\n"
+ " LogicalAggregate(group=[{1}])\n"
+ "EnumerableTableScan(table=[[hr, MV0]])\n"
+ "LogicalAggregate(group=[{1}])\n"
+ " EnumerableTableScan(table=[[hr, MV0]])"
).ok();
}{code}
The test case above will fail because the second mv0 not be matched.
The root cause is that SubstitutionVisitor replace child nodes with
targetDescendant node itself, not a deep-copy replica, so they may share the
same node and the same parent node, so the incorrect parent relationship may
occur, it will make stopTrying be wrong.
> SubstitutionVisitor stop trying incorrect subtree because of wrong parent
> relationship when replace query
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" =
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mou Wu updated CALCITE-6193:
Summary: SubstitutionVisitor stop trying incorrect subtree because wrong
parent relationship when replace query (was: SubstitutionVisitor stop trying
incorrect subtree because wrong parent relationship when attempt)
> SubstitutionVisitor stop trying incorrect subtree because wrong parent
> relationship when replace query
> --
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, so the incorrect parent relationship may
> occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because of wrong parent relationship when replace query
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mou Wu updated CALCITE-6193:
Summary: SubstitutionVisitor stop trying incorrect subtree because of wrong
parent relationship when replace query (was: SubstitutionVisitor stop trying
incorrect subtree because wrong parent relationship when replace query)
> SubstitutionVisitor stop trying incorrect subtree because of wrong parent
> relationship when replace query
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, so the incorrect parent relationship may
> occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because wrong parent relationship when attempt
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mou Wu updated CALCITE-6193:
Summary: SubstitutionVisitor stop trying incorrect subtree because wrong
parent relationship when attempt (was: SubstitutionVisitor stop trying
incorrect subtree because wrong parent relationship when attempte)
> SubstitutionVisitor stop trying incorrect subtree because wrong parent
> relationship when attempt
>
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, so the incorrect parent relationship may
> occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6193) SubstitutionVisitor stop trying incorrect subtree because wrong parent relationship when attempte
[
https://issues.apache.org/jira/browse/CALCITE-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mou Wu updated CALCITE-6193:
Summary: SubstitutionVisitor stop trying incorrect subtree because wrong
parent relationship when attempte (was: SubstitutionVisitor stop try incorrect
subtree because wrong parent relationship when attempte)
> SubstitutionVisitor stop trying incorrect subtree because wrong parent
> relationship when attempte
> -
>
> Key: CALCITE-6193
> URL: https://issues.apache.org/jira/browse/CALCITE-6193
> Project: Calcite
> Issue Type: Bug
>Reporter: Mou Wu
>Assignee: Mou Wu
>Priority: Major
>
> {code:java}
> @Test void testStopTryIncorrectSubtree() {
> final String mv = ""
> + "select \"empid\", \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"empid\", \"deptno\"";
> final String query = ""
> + "select t1.\"deptno\"\n"
> + "from (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "union all\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t1 inner join (\n"
> + "select \"deptno\"\n"
> + "from \"emps\"\n"
> + "where \"salary\" > 1000\n"
> + "group by \"deptno\"\n"
> + ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
> sql(mv, query)
> .checkingThatResultContains(""
> + "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
> + " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
> + "LogicalUnion(all=[true])\n"
> + " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
> expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
> + "LogicalTableScan(table=[[hr, emps]])\n"
> + " LogicalAggregate(group=[{1}])\n"
> + "EnumerableTableScan(table=[[hr, MV0]])\n"
> + "LogicalAggregate(group=[{1}])\n"
> + " EnumerableTableScan(table=[[hr, MV0]])"
> ).ok();
> }{code}
> The test case above will fail because the second mv0 not be matched.
> The root cause is that SubstitutionVisitor replace child nodes with
> targetDescendant node itself, not a deep-copy replica, so they may share the
> same node and the same parent node, so the incorrect parent relationship may
> occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6193) SubstitutionVisitor stop try incorrect subtree because wrong parent relationship when attempte
Mou Wu created CALCITE-6193:
---
Summary: SubstitutionVisitor stop try incorrect subtree because
wrong parent relationship when attempte
Key: CALCITE-6193
URL: https://issues.apache.org/jira/browse/CALCITE-6193
Project: Calcite
Issue Type: Bug
Reporter: Mou Wu
Assignee: Mou Wu
{code:java}
@Test void testStopTryIncorrectSubtree() {
final String mv = ""
+ "select \"empid\", \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"empid\", \"deptno\"";
final String query = ""
+ "select t1.\"deptno\"\n"
+ "from (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "union all\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t1 inner join (\n"
+ "select \"deptno\"\n"
+ "from \"emps\"\n"
+ "where \"salary\" > 1000\n"
+ "group by \"deptno\"\n"
+ ") as t2 on t1.\"deptno\" = t2.\"deptno\"\n";
sql(mv, query)
.checkingThatResultContains(""
+ "LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])\n"
+ " LogicalJoin(condition=[=($0, $1)], joinType=[inner])\n"
+ "LogicalUnion(all=[true])\n"
+ " LogicalCalc(expr#0..4=[{inputs}], expr#5=[1000],
expr#6=[>($t3, $t5)], deptno=[$t1], $condition=[$t6])\n"
+ "LogicalTableScan(table=[[hr, emps]])\n"
+ " LogicalAggregate(group=[{1}])\n"
+ "EnumerableTableScan(table=[[hr, MV0]])\n"
+ "LogicalAggregate(group=[{1}])\n"
+ " EnumerableTableScan(table=[[hr, MV0]])"
).ok();
}{code}
The test case above will fail because the second mv0 not be matched.
The root cause is that SubstitutionVisitor replace child nodes with
targetDescendant node itself, not a deep-copy replica, so they may share the
same node and the same parent node, so the incorrect parent relationship may
occur, it will make stopTrying be wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6190) Incorrect precision derivation for negative numeric types
[
https://issues.apache.org/jira/browse/CALCITE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated CALCITE-6190:
Description:
Test highlights the problem :
{code:java}
@Test void testTypeOfAs() {
sql("select DECIMAL '100.01' as c1 from (values (true))")
.columnType("DECIMAL(5, 2) NOT NULL");
sql("select DECIMAL '-100.01' as c1 from (values (true))")
.columnType("DECIMAL(5, 2) NOT NULL");
}
{code}
Throws exception for second expression:
{noformat}
Expected: is "DECIMAL(5, 2) NOT NULL"
but: was "DECIMAL(6, 2) NOT NULL"
{noformat}
Seems root cause in SqlLiteral#createExactNumeric precision derivation not
consider negative numbers.
was:
Test highlights the problem :
{code:java}
@Test void testTypeOfAs() {
sql("select DECIMAL '*100.01*' as c1 from (values (true))")
.columnType("DECIMAL(*5, 2*) NOT NULL");
sql("select DECIMAL '*-100.01*' as c1 from (values (true))")
.columnType("DECIMAL(*5, 2*) NOT NULL");
}
{code}
Throws check exception for second expression:
{noformat}
Expected: is "DECIMAL(5, 2) NOT NULL"
but: was "DECIMAL(6, 2) NOT NULL"
{noformat}
Seems root cause in SqlLiteral#createExactNumeric precision derivation not
consider negative numbers.
> Incorrect precision derivation for negative numeric types
> -
>
> Key: CALCITE-6190
> URL: https://issues.apache.org/jira/browse/CALCITE-6190
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Evgeny Stanilovsky
>Priority: Major
>
> Test highlights the problem :
> {code:java}
> @Test void testTypeOfAs() {
> sql("select DECIMAL '100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> sql("select DECIMAL '-100.01' as c1 from (values (true))")
> .columnType("DECIMAL(5, 2) NOT NULL");
> }
> {code}
> Throws exception for second expression:
> {noformat}
> Expected: is "DECIMAL(5, 2) NOT NULL"
> but: was "DECIMAL(6, 2) NOT NULL"
> {noformat}
> Seems root cause in SqlLiteral#createExactNumeric precision derivation not
> consider negative numbers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6119) Upgrade test-containers to 1.19.3
[ https://issues.apache.org/jira/browse/CALCITE-6119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ran Tao updated CALCITE-6119: - Description: One of the main features is a fixing for SELinux users (1.19.1). https://github.com/testcontainers/testcontainers-java/pull/6294 bugfixes(1.19.3) 1. Register default network alias using ContainerDef 2. Fix regression using GenericContainer#setImage release notes: https://github.com/testcontainers/testcontainers-java/releases/tag/1.19.3 was: One of the main features is a fixing for SELinux users (1.19.1). testcontainers/testcontainers-java#6294 bugfixes(1.19.3) Register default network alias using ContainerDef Fix regression using GenericContainer#setImage release notes: https://github.com/testcontainers/testcontainers-java/releases/tag/1.19.3 > Upgrade test-containers to 1.19.3 > - > > Key: CALCITE-6119 > URL: https://issues.apache.org/jira/browse/CALCITE-6119 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.36.0 >Reporter: Ran Tao >Priority: Minor > Labels: pull-request-available > Fix For: 1.37.0 > > > One of the main features is a fixing for SELinux users (1.19.1). > https://github.com/testcontainers/testcontainers-java/pull/6294 > bugfixes(1.19.3) > 1. Register default network alias using ContainerDef > 2. Fix regression using GenericContainer#setImage > release notes: > https://github.com/testcontainers/testcontainers-java/releases/tag/1.19.3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6192) DEFAULT expression with NULL value throws unexpected exception
Evgeny Stanilovsky created CALCITE-6192:
---
Summary: DEFAULT expression with NULL value throws unexpected
exception
Key: CALCITE-6192
URL: https://issues.apache.org/jira/browse/CALCITE-6192
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Evgeny Stanilovsky
Processing of DEFAULT expression was improved in scope of [1] but seems there
is one case with NULL as value is not covered and processed erroneously.
{code:java}
create table tdef1 (i int not null, col1 int default null);
insert into tdef1(i, col1) values (1, DEFAULT);
{code}
throws :
{code:java}
Error while executing SQL "insert into tdef1(i, col1) values (1, DEFAULT)":
class org.apache.calcite.sql.SqlLiteral: NULL
{code}
[1] https://issues.apache.org/jira/browse/CALCITE-5950
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
