[
https://issues.apache.org/jira/browse/FLINK-25273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Visser closed FLINK-25273.
----------------------------------
Resolution: Not A Bug
Hi and thanks for opening this ticket. It's better to bring this up for
discussion on the Dev mailing list. See https://flink.apache.org/community.html
on how to do this. You could also comment on the Jira ticket you're referring
to, but I think the Dev mailing list is better suited.
> 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
> Priority: Major
>
> 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)
