wangtiga commented on code in PR #25033:
URL: https://github.com/apache/shardingsphere/pull/25033#discussion_r1160761043
##########
sql-parser/dialect/postgresql/src/main/java/org/apache/shardingsphere/sql/parser/postgresql/visitor/statement/impl/PostgreSQLStatementSQLVisitor.java:
##########
@@ -350,7 +350,7 @@ private Optional<String> findBinaryOperator(final
AExprContext ctx) {
}
private BinaryOperationExpression
createPatternMatchingOperationSegment(final AExprContext ctx) {
- String operator = getOriginalText(ctx.patternMatchingOperator());
+ String operator =
getOriginalText(ctx.patternMatchingOperator()).toUpperCase();
Review Comment:
> There seems to be some problems with the processing of LIKE in MySQL.
Usually, the SQL parsing engine should not change the content of SQL, but
standardize the SQL AST during the SQL Bind stage. It's going to take a lot of
extra work to get this done though, so let's merge this PR first to make sure
the functionality is correct.
Thank you for your patient explanation. The similar issue in
`OpenGaussStatementSQLVisitor` has been fixed and committed. The problem of
directly assigning `LIKE` or `NOT LIKE` to `BinaryOperationExpression.operator`
exists in MySQL and SQLServer as well.
https://github.com/apache/shardingsphere/blob/5.3.1/sql-parser/dialect/sqlserver/src/main/java/org/apache/shardingsphere/sql/parser/sqlserver/visitor/statement/impl/SQLServerStatementSQLVisitor.java#L435
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
