Skip to content

Conversation

@snuyanzin
Copy link
Contributor

@snuyanzin snuyanzin commented Aug 2, 2025

The PR to allow usage of hyphens in unquoted table names for dialects with backticks (not only BigQuery)

};

sql("select * from foo-bar.baz cross join (select alpha-omega from t) as t")
.withDialect(MYSQL)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

mysql was picked here since it has backticks

Copy link
Contributor

Choose a reason for hiding this comment

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

This test and the one following it look identical. Yet one is supposed to succeed and the other to fail. How does that work?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I updated tests to have same as for BigQuery

CharLiteralStyle.BQ_DOUBLE))) {
CharLiteralStyle.BQ_DOUBLE))
|| config.charLiteralStyles().equals(
EnumSet.of(CharLiteralStyle.STANDARD)))) {
Copy link
Contributor

Choose a reason for hiding this comment

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

With this change, any dialect whose allowHyphenInUnquotedTableName returns true will allow identifiers with back-ticks. I don't think anyone will expect that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

then it is not clear what is the purpose of allowHyphenInUnquotedTableName returning true then?
Isn't this what is meant in javadoc

* Whether to allow hyphens in an unquoted table name.
*
* <p>If true, {@code SELECT * FROM foo-bar.baz-buzz} is valid, and is parsed
* as if the user had written {@code SELECT * FROM `foo-bar`.`baz-buzz`}.

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, suppose someone has asked for Oracle-style quoted identifiers, "my table". If they also make allowHyphenInUnquotedTableName return true then they aren't going to get the parser behavior that they asked for.

Copy link
Contributor Author

@snuyanzin snuyanzin Aug 5, 2025

Choose a reason for hiding this comment

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

yes, same happens without this PR changes, and makes me thinking that javadoc doesn't reflect current behavior...

Initially (also put in jira description) I was thinking to make it working for backticks quoting only.
Do you think it would make sense to make it working for all (asking since so far I don't know other well known DB vendors supporting this)

Copy link
Contributor

Choose a reason for hiding this comment

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

You should take the time to understand how it currently works. The implementation is subtle.

Lexical states are a very clever tool (I introduced them myself, to allow switching between quoting styles) but they are costly. Each lexical state creates a whole new copy of the parser's transition table and therefore makes the parser much larger.

Therefore we should only support the combinations that people actually need.

Relying on the sets of literal styles to deduce that we are dealing with BigQuery was a hack on my part. (See https://issues.apache.org/jira/browse/CALCITE-4247.) But that doesn't give you license to make the hack worse. In fact, if you want to change things, you have to figure out a way to make things better.

@sonarqubecloud
Copy link

sonarqubecloud bot commented Aug 3, 2025

@github-actions
Copy link

github-actions bot commented Sep 5, 2025

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 90 days if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@calcite.apache.org list. Thank you for your contributions.

@github-actions github-actions bot added stale and removed stale labels Sep 5, 2025
@github-actions
Copy link

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 90 days if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@calcite.apache.org list. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants