[
https://issues.apache.org/jira/browse/CALCITE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926427#comment-17926427
]
Sree Harsha Ramanavarapu edited comment on CALCITE-6819 at 2/12/25 3:48 PM:
----------------------------------------------------------------------------
I have opened a new PR to fix the issue listed in the current Jira. The fix is
similar to the one suggested in CALCITE-6482.
Regarding other cases:
1) WHERE TRUE - eliminated by calcite optimizer and hence is not part of the
final Sql statement.
2) HAVING TRUE - also eliminated.
3) SELECT TRUE - IMHO this is a different problem. MSSQL allows only conditions
(=, <>, < etc) in the Join condition. It allows only expressions in the SELECT
List (or VALUES clause). This is transformed into:
SELECT * FROM (VALUES (TRUE)) AS t (EXPR$0)
with the current fix, it will be transformed to
SELECT * FROM (VALUES (1 = 1)) AS t (EXPR$0)
which will also give an because only literals and expressions are allowed in
the VALUES caluse.
The current logic of handling this in the unparse phase of each dialect's
literal is unable to address this issue. It might require a different to fix
the issue. I have opened a different Jira to track this issue:
https://issues.apache.org/jira/browse/CALCITE-6829
was (Author: JIRAUSER305541):
I have opened a new PR to fix the issue listed in the current Jira. The fix is
similar to the one suggested in CALCITE-6482.
Regarding other cases:
1) WHERE TRUE - eliminated by the optimizer and hence is not part of the final
Sql statement.
2) HAVING TRUE - also eliminated.
3) SELECT TRUE - IMHO this is a different problem. MSSQL allows only conditions
(=, <>, < etc) in the Join condition. It allows only expressions in the SELECT
List (or VALUES clause). This is transformed into:
SELECT * FROM (VALUES (TRUE)) AS t (EXPR$0)
with the current fix, it will be transformed to
SELECT * FROM (VALUES (1 = 1)) AS t (EXPR$0)
which will also give an because only literals and expressions are allowed in
the VALUES caluse.
The current logic of handling this in the unparse phase of each dialect's
literal is unable to address this issue. It might require a different to fix
the issue. I have opened a different Jira to track this issue:
https://issues.apache.org/jira/browse/CALCITE-6829
> MSSQL doesn't support TRUE/FALSE keywords in its Join predicate
> ---------------------------------------------------------------
>
> Key: CALCITE-6819
> URL: https://issues.apache.org/jira/browse/CALCITE-6819
> Project: Calcite
> Issue Type: Bug
> Reporter: Sree Harsha Ramanavarapu
> Priority: Major
> Labels: pull-request-available
>
> CREATE TABLE t1 (c11 int, c12 int);
> INSERT INTO t1 VALUES (1,10), (2,20), (3,30);
> CREATE TABLE t2 (c21 int, c22 int);
> SELECT * FROM t1 LEFT OUTER JOIN t2 ON TRUE;
> Msg 4145, Level 15, State 1, Server a08c6f7cfc77, Line 9
> An expression of non-boolean type specified in a context where a condition is
> expected, near ';'.
> TRUE/FALSE are not supported in MSSQL (but it is supported in most DBs).
> The MSSQL way would be to write the query as :
> SELECT * FROM t1 LEFT OUTER JOIN t2 ON 1=1;
> MSSQL dialect should support this syntax.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
