BryanOnKeys opened a new issue, #12998: URL: https://github.com/apache/seatunnel/issues/12998
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/seatunnel/issues?q=is%3Aissue+label%3A%22bug%22) and found no similar issues. ### What happened `SqlWhereConditionHelper` can miss the main `FROM` after a Unicode character whose uppercase form has a different length. With an existing `t.*` projection, applying `where_condition` then adds a column already supplied by the wildcard and produces invalid SQL. This is a separate, pre-existing issue from #12995 / #12996: I reproduced it on both the base commit and the PR helper, with `Locale.ROOT` as the default locale. ### Reproduction Using the unchanged helper source, run: ```java Locale.setDefault(Locale.ROOT); String sql = "select id as maß, t.* from t"; System.out.println(SqlWhereConditionHelper.hasTopLevelSelectWildcard(sql)); System.out.println(SqlWhereConditionHelper.applyWhereConditionWithWrap( sql, "name = 'x'", true)); ``` Actual output: ```text false SELECT * FROM (select name,id as maß, t.* from t) tmp WHERE name = 'x' ``` For an H2 2.3.232 JDBC check, I created: ```sql create table t(id int, name varchar(20)); insert into t values(1, 'x'), (2, 'y'); ``` The unmodified wrapper executes successfully and returns one row: ```sql SELECT * FROM (select id as maß, t.* from t) tmp WHERE name = 'x' ``` The helper-generated query fails with duplicate column `NAME` (see exception below). As an ASCII control, `select id as size, t.* from t` correctly reports a wildcard and the generated wrapper returns one row with columns `SIZE,ID,NAME`. Both controls and the failure were verified on both helper versions. ### Expected behavior Recognize `t.*` and keep the original inner projection: `name` is already available through the wildcard. ### Cause `findMainFromClauseIndex` walks indices in the original SQL but checks `upperSql.startsWith("FROM", i)` after uppercasing the whole string. `ß` expands to `SS`, so those indices no longer align. This causes wildcard detection to include the `FROM` clause in its final column token, miss `t.*`, and fall back to adding `name`. `Locale.ROOT` does not prevent this length expansion. Keyword matching needs to preserve indices in the original SQL. Validation scope: isolated helper compilation and a real in-memory H2 JDBC execution; I did not run a SeaTunnel engine job or the full Maven/Docker integration suite. ### SeaTunnel Version 3.1.0-SNAPSHOT helper source: - dev base: 7b686d8387557ae4d90de35176d6dcafdc0e1fff - Also reproduced with the helper at PR #12996 head b205f49ea59742d0c61e80354316a375c92a04e3. The same failure occurs in both; this report does not attribute it to that PR. ### SeaTunnel Config ```conf # Relevant JDBC source options only; not a full executed job config. query = "select id as maß, t.* from t" where_condition = "name = 'x'" ``` ### Running Command ```shell # No SeaTunnel engine job was run. I used a standalone Java/JDBC reproducer # invoking the helper calls above, then executed the original and generated # wrappers through DriverManager.getConnection("jdbc:h2:mem:unicode_review"). # Command shape (substitute the compiled classes and dependency jar paths): java -cp "<compiled-helper-and-reproducer>:<shaded-commons-lang3-jar>:<slf4j-api-jar>:h2-2.3.232.jar" SqlUnicodeJdbcRepro ``` ### Error Exception ```log Duplicate column name "NAME"; SQL statement: SELECT * FROM (select name,id as maß, t.* from t) tmp WHERE name = 'x' [42121-232] ``` ### Zeta or Flink or Spark Version Not used: isolated helper / JDBC reproduction. ### Java or Scala Version OpenJDK 17.0.20; helper compiled with --release 8. H2 2.3.232. Helper dependencies used the project POM versions: seatunnel-shade-commons-lang3 3.18.0-3.0.0, Lombok 1.18.36, SLF4J API 1.7.36. ### Screenshots _No response_ ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
