LuciferYang opened a new issue, #9619:
URL: https://github.com/apache/paimon/issues/9619

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   ### Paimon version
   
   master, `475be566f` (2.1-SNAPSHOT).
   
   ### Compute Engine
   
   Any. The cast runs wherever a column default value is materialized, so 
Flink, Spark and the Java API all reach it.
   
   ### Minimal reproduce step
   
   Give a MAP column a default value whose key or value contains an escaped 
separator:
   
   ```sql
   CREATE TABLE t (
     id INT,
     tags MAP<STRING, STRING>
   ) WITH ('fields.tags.default-value' = '{a\,b -> v}');
   ```
   
   The key comes out as `ab`, not `a,b`. Both the backslash and the comma it 
escaped are gone. Directly on the cast:
   
   ```java
   CastExecutor<BinaryString, InternalMap> cast =
           CastExecutors.resolve(
                   VarCharType.STRING_TYPE, new MapType(DataTypes.STRING(), 
DataTypes.STRING()));
   cast.cast(BinaryString.fromString("{a\\,b -> v\\\\1}"));
   // key "ab", value "v1"; expected key "a,b", value "v\1"
   ```
   
   `StringToMapCastRule.splitMapEntries` consumed the escaped character without 
keeping it:
   
   ```java
   for (char c : content.toCharArray()) {
       if (escaped) {
           escaped = false;
           continue;          // the escaped character is dropped here
       } else if (c == '\\') {
           escaped = true;
           continue;          // and its backslash here
       }
       ...
   ```
   
   The escape does stop the comma from splitting the entry, so the entry count 
is right, but the character itself never reaches the parsed key or value. No 
error is raised, so the table is created with a default value that differs from 
what was written in the DDL.
   
   ### What doesn't meet your expectations?
   
   An escaped character should survive as a literal, which is the whole point 
of writing `\,`. It is also what the quote handling in the same method already 
does: a quoted section keeps its content and drops the quotes, so `{"a,b" -> 
v}` gives the key `a,b` today. The backslash branch drops the content along 
with the marker.
   
   ### Anything else?
   
   Two related things I did not treat as part of this, in case they matter to 
whoever picks it up.
   
   `ENTRY_PATTERN` splits key from value after the entry has already been 
unescaped, so escaping the `->` delimiter itself cannot work: `{a\->b -> v}` 
parses as key `a`, value `b -> v`. Making that work means splitting key and 
value inside the escape-aware scan rather than with a regex afterwards.
   
   `StringToArrayCastRule` and `StringToRowCastRule` have the same loop but 
append every character, so in those two rules backslashes and quotes survive 
into the parsed element. The map rule strips both. Worth deciding whether all 
three should agree.
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!
   


-- 
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]

Reply via email to