René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[BUG] EXCEPT ALL/DISTINCT and MINUS ALL/DISTINCT modifiers lost during parse-toString round-trip","articleBody":"### Description\n\n`EXCEPT ALL`, `EXCEPT DISTINCT`, `MINUS ALL`, and `MINUS DISTINCT` modifiers are silently dropped during parsing. The parser accepts the modifier syntax but does not pass the captured modifier string to the `ExceptOp` and `MinusOp` constructors.\n\n### Reproducer\n\n```java\nString sql = \"SELECT a FROM t1 EXCEPT ALL SELECT a FROM t2\";\nStatement stmt = CCJSqlParserUtil.parse(sql);\nSystem.out.println(stmt.toString());\n// Expected: SELECT a FROM t1 EXCEPT ALL SELECT a FROM t2\n// Actual:   SELECT a FROM t1 EXCEPT SELECT a FROM t2\n```\n\nThe same issue affects `MINUS ALL`:\n```java\nString sql = \"SELECT a FROM t1 MINUS ALL SELECT a FROM t2\";\nStatement stmt = CCJSqlParserUtil.parse(sql);\nSystem.out.println(stmt.toString());\n// Expected: SELECT a FROM t1 MINUS ALL SELECT a FROM t2\n// Actual:   SELECT a FROM t1 MINUS SELECT a FROM t2\n```\n\n### Root Cause\n\nIn `JSqlParserCC.jjt`, the `SetOperationList` rule captures the modifier via `modifier=SetOperationModifier()` but constructs `MinusOp` and `ExceptOp` with their no-arg constructors (which default to empty string), discarding the modifier:\n\n```\n\u003cK_MINUS\u003e [ modifier=SetOperationModifier() ] { MinusOp minus = new MinusOp(); ... }\n\u003cK_EXCEPT\u003e [ modifier=SetOperationModifier() ] { ExceptOp except = new ExceptOp(); ... }\n```\n\nCompare with `UnionOp` and `IntersectOp` which correctly pass the modifier:\n```\n\u003cK_UNION\u003e [ modifier=SetOperationModifier() ] { UnionOp union = new UnionOp(modifier); ... }\n\u003cK_INTERSECT\u003e [ modifier=SetOperationModifier() ] { IntersectOp intersect = new IntersectOp(modifier); ... }\n```\n\nAdditionally, the `modifier` variable was not reset between iterations of the set-operation loop, causing modifiers to leak from one operator to the next (e.g., `UNION ALL ... EXCEPT` would incorrectly make the EXCEPT inherit `ALL`).\n\n### Impact\n\n- **Semantic correctness**: `EXCEPT ALL` preserves duplicates while `EXCEPT` removes them. Silently dropping the `ALL` modifier changes query semantics.\n- **Round-trip fidelity**: `parse(sql).toString()` does not reproduce the original SQL.\n\n### Affected versions\n\nCurrent `master` (regression introduced in commit `5fe938bc` which refactored `SetOperationModifier` handling for the `CORRESPONDING` feature).\n\n### Fix\n\n1. Pass `modifier` to `MinusOp` and `ExceptOp` constructors\n2. Reset `modifier = null` at the start of each set-operation loop iteration\n\nA PR with the fix and regression tests will follow.","author":{"url":"https://github.com/queelius","@type":"Person","name":"queelius"},"datePublished":"2026-03-25T10:46:56.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/2419/JSqlParser/issues/2419"}