You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Jianhui Dong (Jira)" <ji...@apache.org> on 2021/12/13 07:47:00 UTC

[jira] [Created] (FLINK-25273) Some doubts about the FLINK-22848

Jianhui Dong created FLINK-25273:
------------------------------------

             Summary: Some doubts about the FLINK-22848
                 Key: FLINK-25273
                 URL: https://issues.apache.org/jira/browse/FLINK-25273
             Project: Flink
          Issue Type: Improvement
          Components: Table SQL / API
            Reporter: Jianhui Dong


I have been in contact with Flink and Calcite for a while, and I have some questions about this issue: https://issues.apache.org/jira/browse/FLINK-22848.
First of all, the discussion about this issue mentioned that since calcite did not support the syntax analysis of set a=b (without quotes), regular expressions were used. However, I checked the commit history some days ago, and I found that calcite should already support SET syntax parsing (see SqlSetOption) in v1.14 or even earlier. but its problem is that it would recognize the `true/false/unknown/null` tokens as keywords, causing the parsing to be worse than expected, but this problem can be solved by restricting the syntax, like use '' in the issue FLINK-22848.
Then I investigated the earliest version of flink that introduced calcite, flink should have introduced Calcite 1.16 in 1.5 at the earliest version. At that time, calcite should already support the syntax of SET a=b (without quotes), so I would like to find out What exactly does the "not supported" mentioned in the issue FLINK-22848 means? Maybe you can give a more specific case.
In addition, I also have some doubts about the results of the discussion of the issue. I think it is indeed a more elegant solution to use the SQL parser to analyze it, but When calcite has built-in support for SET grammar, why do we need to extend the SET grammar to re-support it? Even this change may cause backward-incompatible.
In my personal opinion of view, is that we can solve this problem by adding special restrictions on the above tokens on the basis of native Calcite analysis, such as in the user manual because values ​​such as `unknown` and `null` are meaningless in the production environment. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)