DBeaver 25.0.5.202505181758 Misparses Valid Unquoted Alias year_month as Syntax Error with MySQL 8.0.35

[TheRakeshMishra]

Description

Environment:

• DBeaver Version: 25.0.5.202505181758
• Operating System: Windows 11
• Database Type and Version: MySQL Server 8.0.35-0ubuntu0.22.04.1

Problem Description:
DBeaver appears to incorrectly report a SQL syntax error (1064) when using the unquoted alias year_month in a SELECT statement against a MySQL 8.0.35 server. MySQL server itself accepts this syntax without issue. The error message often includes DBeaver's default LIMIT clause appended directly after the problematic alias, suggesting a client-side parsing or query construction issue before the query is fully sent or processed by the server.

The issue seems specific to the exact unquoted identifier year_month. Other similar unquoted identifiers containing underscores, or slight variations, work correctly.

Thank you for your great work on DBeaver! We hope this detailed report helps in identifying and resolving this specific parsing behavior.

DBeaver Version

25.0.5.202505181758

Operating System

Windows 11

Database and driver

No response

Steps to reproduce

Steps to Reproduce:

1. Connect to a MySQL 8.0.35 database.
2. Open a new SQL editor.
3. Execute the following simple query:

   SELECT 1 AS year_month;

Expected Behavior:
The query should execute successfully without errors, returning one row with one column named year_month containing the value 1.

Actual Behavior:
DBeaver reports a SQL error:

SQL Error [1064] [42000]: (conn=XXXXXXXX) You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'year_month LIMIT 0, 200' at line 1

(Note: conn=XXXXXXXX will vary)

The same error occurs with more complex queries, for example:

SELECT
    DATE_FORMAT(SETUP_DATETIME, '%Y-%m') AS year_month,
    COUNT(*) AS total_entries
FROM
    game -- (assuming 'game' table with 'SETUP_DATETIME' column exists)
GROUP BY
    year_month;

This also results in a 1064 error pointing near year_month, COUNT(*)....

Additional context

Additional Context / Working Examples:
The following variations execute successfully in DBeaver, highlighting the specificity of the issue with the unquoted year_month:

1. Alias without underscore:

   SELECT 1 AS yearmonth; -- WORKS

2. Different alias with underscore:

   SELECT 1 AS y_m; -- WORKS

3. Slightly different alias with underscore and keyword-like parts:

   SELECT 1 AS years_months; -- WORKS

4. Problematic alias with backticks (quoted identifier):

   SELECT 1 AS `year_month`; -- WORKS

Hypothesis:
It appears DBeaver's internal SQL parser or validator incorrectly identifies the specific unquoted string year_month as a reserved keyword or a syntactically invalid construct. This might be due to the combination of year and month (which are known SQL keywords/functions) being separated by an underscore in an unquoted context, leading to a misinterpretation before the query is correctly relayed to the MySQL server. The fact that years_months (with an 's') works, while year_month doesn't, strongly suggests a very specific pattern match is causing the issue in DBeaver's parser.

Workarounds:

1. Use backticks to quote the alias: AS \year_month``.
2. Use a different alias name that doesn't trigger the issue (e.g., yearmonth, entry_year_month, years_months).

[E1izabeth]

DBeaver sends your query to the database as is. The error that you receive is the database response. year_month is a reserved word and can't be used without backticks (You can check it in a full list of the reserved words in MySQL docs https://dev.mysql.com/doc/refman/8.4/en/keywords.html#keywords-in-current-series)

[TheRakeshMishra]

Hi @E1izabeth

Thank you very much for the quick response and the link to the MySQL reserved keywords documentation.

You are absolutely correct, and I sincerely apologize for the oversight. I had re-checked the list, but somehow completely missed YEAR_MONTH being present. My mistake entirely!

With YEAR_MONTH being a reserved keyword, the syntax error I encountered when using AS year_month without quotes is indeed the expected behavior from the MySQL server. My tests with other aliases like y_m and years_months worked because those are not reserved, which should have been a clearer indicator for me.

It seems I might have been a bit overly confident in some earlier checks and discussion, perhaps relying too much on an AI assistant's initial (and in this case, incorrect) confirmation that it wasn't reserved. A good lesson to always go back to the primary source documentation!

Thank you again for your time and for setting me straight on this. I appreciate your help and will close this issue.

Best regards