[ 
https://issues.apache.org/jira/browse/CALCITE-5265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17602138#comment-17602138
 ] 

Julian Hyde commented on CALCITE-5265:
--------------------------------------

I agree, the parentheses don't seem necessary. Maybe the unparser is getting 
the relative precedence of INSERT and SELECT slightly wrong.

Ideally this should be unparsed to something that looks very much like the 
original, "insert into \"DEPT\" values (?,?,?)". RelToSqlConverter should 
remove all of the layers of RelNodes that were added so that it makes sense in 
relational algebra.

When fixing this, also check that "INSERT INTO aTable SELECT .. FROM 
anotherTable" and "INSERT INTO aTable SELECT .. FROM anotherTable UNION SELECT 
.. FROM yetAnotherTable" with the right number of parentheses.



> Select operator' parentheses should be same with Union operator
> ---------------------------------------------------------------
>
>                 Key: CALCITE-5265
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5265
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Mou Wu
>            Assignee: Mou Wu
>            Priority: Trivial
>
> Add a case in RelToSqlConverterTest:
> {code:java}
> // code placeholder
> @Test void testInsertValueWithDynamicParams() {
>   final String sql = "insert into \"DEPT\" values (?,?,?)";
>   final String expected = ""
>       + "INSERT INTO \"SCOTT\".\"DEPT\" (\"DEPTNO\", \"DNAME\", \"LOC\")\n"
>       + "SELECT ? AS \"DEPTNO\", ? AS \"DNAME\", ? AS \"LOC\"\n"
>       + "FROM (VALUES (0)) AS \"t\" (\"ZERO\")";
>   sql(sql)
>       .schema(CalciteAssert.SchemaSpec.JDBC_SCOTT)
>       .ok(expected);
> }{code}
> will fail, because actual sql is with parentheses, maybe it's all right with 
> parentheses, but the behavior is different from Union operator, you can see 
> testInsertValuesWithDynamicParams in RelToSqlConverterTest class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to