[Bug]: sql未正确输入结束但被解析为语法正确的statement #363

Activity

1. mumiao

   assigned

   JackWang032

   on Nov 14, 2024
2. JackWang032 commented on Mar 28, 2025

   

   JackWang032

   on Mar 28, 2025

   CollaboratorAuthor

   More actions

   这是由于所有类型 SQL 中语句结束符分号都是可选的导致的，考虑可以通过 action 的方式往g4中注入运行时代码，当进行getSuggestion时使分号必选以进行正确的 SQL 切分。

   
3. liuxy0551 commented on Sep 22, 2026

   

   liuxy0551

   on Sep 22, 2026

   Last edited by liuxy0551

   Collaborator

   More actions

   该问题已在 PR #485 中一并解决。虽然 PR 关联的是 #436，但两个问题的根因相同：由于各方言的语句结束分号可选，ANTLR4-C3 从 program 规则收集候选时，会认为当前语句已经结束，并继续收集下一条 statement 的起始关键字。
   最终没有采用在各方言 g4 中注入 action、补全时强制分号的方案，而是在公共补全逻辑中进行 statement 级候选隔离：

   1. 保留从 program 收集的候选，避免丢失外层 grammar rule 信息；
   2. 根据光标位置定位当前顶层 statement，并单独收集当前 statement 的候选；
   3. 过滤只属于下一条语句开头的关键字；
   4. 对当前 statement 中仍然合法的关键字，保留其 follow-list 和组合关键字。
      这样不会修改正常 SQL 解析规则，也能同时保证：

   • 无分号时只提示当前语句的合法续写关键字；
   • 输入分号后仍可提示下一条语句；
   • 多语句、未完成单词和组合关键字补全正常；
   • MySQL、FlinkSQL、SparkSQL、HiveSQL、PostgreSQL、TrinoSQL、ImpalaSQL、GenericSQL 均有回归覆盖。
     当前在 CREATE TABLE table1 表名后输入空格，只会返回 AS、LIKE、COMMENT、PARTITIONED BY 等当前建表语句的候选，不再混入 SELECT、CREATE、DROP 等下一语句起始关键字。
     该修复已随 v4.5.1 发布，因此本 Issue 可以关闭。

   
4. liuxy0551

   assigned

   liuxy0551

   and unassigned

   JackWang032

   on Sep 22, 2026