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

Timo Walther edited comment on FLINK-22770 at 5/25/21, 12:16 PM:
-----------------------------------------------------------------

I agree with [~airblader]. Maintaining two parsers is not a good idea. Esp. if 
the first level parser is only based on regular expressions. This will be 
error-prone and hard to maintain when we implement more SQL statements in the 
future. All Flink components should use the SQL parser (with or without table 
environment) to parse strings into operations. This issue is a first step 
towards this goal but without breaking backwards compatibility as the old regex 
parser remains in place.


was (Author: twalthr):
I agree with [~airblader]. Maintaining two parsers is not a good idea. Esp. if 
the first level parser is only based on regular expressions. This will be 
error-prone and hard to maintain when we implement more SQL statements in the 
future. All Flink components should use the SQL parser (with or without table 
environment) to parse strings into operations. This issue is a first step 
towards this goal but without breaking backwards compatibility as the old regex 
parser remain in place.

> Expose SET/RESET from the parser
> --------------------------------
>
>                 Key: FLINK-22770
>                 URL: https://issues.apache.org/jira/browse/FLINK-22770
>             Project: Flink
>          Issue Type: New Feature
>          Components: Table SQL / API, Table SQL / Planner
>    Affects Versions: 1.13.0
>            Reporter: Ingo Bürk
>            Assignee: Ingo Bürk
>            Priority: Minor
>
> The SET/RESET statements (DCL¹) are currently implemented using regular 
> expressions in the ExtendedParser. They should instead be properly added to 
> the grammar and parser.
> In a second step, the ExtendedParser implementation for it can be removed. 
> However, this would be a breaking change as key/value would then have to be 
> quoted (as they are in other places, i.e. table options) and no longer be 
> treated as SQL identifiers.
> ¹ SET also exists in a no-argument version where it becomes DQL. For the 
> scope of this issue I'm excluding this here.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to