Repository navigation
[BUG] JSQLParser 5.4-SNAPSHOT : MySQL : # line comments are not supported #2499
Description
Activity
Do we really need/want that? I have not problem with
\n# this is a commentbutSELECT 1 # commentadds lots of complexity, when at the same time there is SQL:2016. Why can't we expect MySQL doing things in a sane way?@manticore-projects lexically both forms are the same rule and the trailing one adds no complexity beyond the own-line one: a
#to end of line token that does not match when#is immediately followed by>keeps#>/#>>intact through longest match, the same mechanism that already separates/from/*(SELECT 4 / 2andSELECT 1 /* c */ + 2both parse on master). Restricting the comment to line-initial#would take more machinery than covering both, since javacc token regexes have no line anchor.On the last question:
#is long-documented MySQL syntax, so the SQL users feed the parser contains it regardless of what MySQL does next.Whether MySQL-specific comments are in scope is your call. If anyone else runs into this and asks about it or opens a PR, I can help; closing this is fine too if you prefer pointing users at
--(with the trailing space MySQL requires).My own point of view: if you can implement it as a "low hanging fruit" w/o much code or extra grammar, then I am not against it. But if it makes the large and complicated grammar even more complex, then I won't like it -- because all of this also needs to be maintained in the future and I just do not see any good reason for this standard deviation (or for MySQL :-) )
- added a commit that references this issue
on Aug 25, 2026 - added a commit that references this issue
on Aug 26, 2026
AI disclosure: this issue was prepared with AI coding agents, reviewed and revised line by line by me.
Failing SQL Feature:
MySQL
#line comments are not parsed. MySQL supports#to end of line as a comment style (MySQL 8.0 Manual, Comments). JSqlParser handles--and/* */, but#fails.Context:
#is currently lexed for the PostgreSQL JSON operators#>and#>>(JSqlParserCC.jjt, token handling around line 8403). A line comment rule must not swallow those: with javacc longest-match, a plain#to end of line token would also consume#>/#>>, so the comment rule needs to exclude a>immediately after#.SQL Example:
A standalone comment line fails the same way:
SELECT 1 -- commentparses fine.Software Information:
1e4e92b(also present in 5.1)