omkar-shitole commented on code in PR #34227:
URL: https://github.com/apache/shardingsphere/pull/34227#discussion_r1948734842
##########
parser/sql/dialect/postgresql/src/main/java/org/apache/shardingsphere/sql/parser/postgresql/visitor/statement/PostgreSQLStatementVisitor.java:
##########
@@ -704,7 +704,7 @@ public ASTNode visitInsert(final InsertContext ctx) {
PostgreSQLInsertStatement result = (PostgreSQLInsertStatement)
visit(ctx.insertRest());
result.setTable((SimpleTableSegment) visit(ctx.insertTarget()));
if (null != ctx.optOnConflict()) {
-
result.setOnDuplicateKeyColumnsSegment((OnDuplicateKeyColumnsSegment)
visit(ctx.optOnConflict()));
+
result.setOnConflictKeyColumnsSegment((OnConflictKeyColumnsSegment)
visit(ctx.optOnConflict()));
Review Comment:
@strongduanmu Thank you for the suggestion! I have started working on your
suggestion.
However IMHO,
- `WHERE` Clause Support: PostgreSQL allows a WHERE condition inside ON
CONFLICT DO UPDATE, whereas MySQL does not support filtering updates this way.
- `DO NOTHING` Behavior: PostgreSQL supports DO NOTHING within ON CONFLICT,
which does not have a direct equivalent in MySQL.
- Conflict Target Specification: PostgreSQL requires explicitly specifying a
conflict target (ON CONFLICT (column)), whereas MySQL automatically handles
conflicts on any unique key.
Considering these differences, modifying `OnDuplicateKeyColumnsSegment `to
accommodate PostgreSQL-specific behaviour might introduce additional
complexity.
Considering the above points I was thinking of having factory methods in
`OnDuplicateKeyColumnsSegment` as `withWhereSegment` and
`withoutWhereSegment`. or we can have the Optional of WhereSegment as a
variable.
Either way, in addition to the above differences between `ON CONFLICT` and
`ON DUPLICATE` grow over time, managing these differences in one class could
lead to complexity and harder-to-manage further.
Please let me know your view on it.
--
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: notifications-unsubscr...@shardingsphere.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
