[BUG] JSQLParser 5.4-SNAPSHOT : MySQL : # line comments are not supported

[fudianchn]

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:

SELECT 1 # comment

net.sf.jsqlparser.JSQLParserException: net.sf.jsqlparser.parser.ParseException: Encountered: <K_COMMENT> / "comment", at line 1, column 12, in lexical state DEFAULT.

A standalone comment line fails the same way:

SELECT 1
# trailing comment

net.sf.jsqlparser.parser.ParseException: Encountered: <K_TRAILING> / "trailing", at line 2, column 3, in lexical state DEFAULT.

SELECT 1 -- comment parses fine.

Software Information:

• JSqlParser version: master 1e4e92b (also present in 5.1)
• Database: MySQL 8.0

[manticore-projects]

Do we really need/want that? I have not problem with \n# this is a comment but SELECT 1 # comment adds lots of complexity, when at the same time there is SQL:2016. Why can't we expect MySQL doing things in a sane way?

[fudianchn]

@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 / 2 and SELECT 1 /* c */ + 2 both 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).

[manticore-projects]

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 :-) )