[
https://issues.apache.org/jira/browse/FLINK-22770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351016#comment-17351016
]
Ingo Bürk edited comment on FLINK-22770 at 5/25/21, 12:23 PM:
--------------------------------------------------------------
Thanks for the background. I understand why it's supported without quotes, and
I don't actually feel strongly about whether we should require quotes or not.
The problem is, however, that we currently cannot support SET in Ververica
Platform because the SQL parser doesn't understand it, and we have to support
multiple statements.
Any type of parsing of complex grammars like SQL with regular expressions is, I
think, a "dangerous" idea, because the grammar isn't regular. Helpers like
CliStatementSplitter seem like bandaid fixes to workaround other issues. After
all, we have a parser precisely for the purpose of parsing SQL.
I'm wondering what a reasonable way forward could be here. I don't think the
future can be to pre-parse SQL using regular expressions, and a breaking change
is of course unfortunate, but if it means actually moving grammar into the
grammar, maybe it's justified (it's also very simple for users to fix their
statements). We've recently done similar things e.g. for the time-related
functions. What do you think?
CC [~twalthr]
was (Author: airblader):
Thanks for the background. I understand why it's supported without quotes, and
I don't actually feel strongly about whether we should require quotes or not.
The problem is, however, that we currently cannot support SET in Ververica
Platform because the SQL parser doesn't understand it, and we have to support
multiple statements.
Any type of parsing of complex grammars like SQL with regular expressions is, I
think, a bad idea, because the grammar isn't regular. Helpers like
CliStatementSplitter seem like bandaid fixes to workaround other issues. After
all, we have a parser precisely for the purpose of parsing SQL.
I'm wondering what a reasonable way forward could be here. I don't think the
future can be to pre-parse SQL using regular expressions, and a breaking change
is of course unfortunate, but if it means actually moving grammar into the
grammar, maybe it's justified (it's also very simple for users to fix their
statements). We've recently done similar things e.g. for the time-related
functions. What do you think?
CC [~twalthr]
> 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)
