Skip to content

[CALCITE-7778] JDBC adapter for MSSQL generates % for MOD without preserving grouping, giving wrong results - #5259

Open
wasabii wants to merge 3 commits into
apache:mainfrom
wasabii:calcite-7778-mssql-mod-grouping
Open

wasabii wants to merge 3 commits into
apache:mainfrom
wasabii:calcite-7778-mssql-mod-grouping

Conversation

@wasabii

@wasabii wasabii commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Jira Link

CALCITE-7778

Changes Proposed

Parenthesize the % written for MOD where its lower precedence requires it. Shared in RelToSqlConverterUtil rather than the dialect, since HiveSqlDialect makes the same substitution and somebody might want to fix that also some day.

* operator before the dialect is consulted, so an operator that binds less
* tightly needs them added here.
*/
public static void unparseWithOperator(SqlWriter writer, SqlOperator operator,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe this should be called "unparseWithBinaryOperator"

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that a change you want me to make?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you find that this would describe better what the function does?

@sonarqubecloud

Copy link
Copy Markdown

@mihaibudiu mihaibudiu left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can squash the commits.
I left one more suggestion for improving the comments.

* Writes a two-operand call with an operator other than its own,
* parenthesized as that operator requires.
*
* <p>{@link SqlCall#unparse} chooses the parentheses from the call's own

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would shorten this comment to say that this will use parentheses when necessary.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder what happens if not all SQL dialects have the same operation precedence...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon staring at it longer, I don't think dialects have any ability to hold per operator precedence, do they?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's frankly probably a good thing to add! If done, we'd pass getLeftPrec and getRightPrec through that I guess.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually. There are a bunch of special operators floating around for specific SQL languages. I guess if this got hit after those were substituted in, it would be fine, if those carried their own special precedence.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In calcite operators cannot change precedences, but I am saying is that the calcite unparse will decide whether to use parens based on the Calcite rules, which may not match the target dialect rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants