[Bug] split_by_string("",',')

[zjj]

Search before asking

• I had searched in the issues and found no similar issues.

Version

3.x 4.x

MySQL [(none)]> select split_by_string("",',');
+-------------------------+
| split_by_string("",',') |
+-------------------------+
| [] |
+-------------------------+

What's Wrong?

select split_by_string("",',') returns []

What You Expected?

select split_by_string("",',') shall return ['']

How to Reproduce?

No response

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_a837ad07af60
This content is generated by AI for reference only.

Initial analysis:

I would treat this as a real code/docs semantic mismatch, not just an unclear report.

On current upstream master, FunctionSplitByString::_execute in be/src/exprs/function/function_string_search.cpp checks an empty source string before delimiter handling. When str_ref.size == 0, it appends the unchanged array offset and continues, so the BE runtime produces zero elements for split_by_string('', ','). The FE constant-folding path in StringArithmetic.splitByString has the same semantic: when the first argument is empty, it returns an empty ArrayLiteral. Existing regression baselines on master, branch-4.1, and branch-3.1 also currently expect [] for the empty-source cases.

However, the current 4.x public function docs say that an empty <str> returns an array with one empty string ([""]), and the original merged PR for split_by_string (#13741) also described the empty-source/non-empty-separator case as selecting an empty substring. That means maintainers need to decide the canonical semantic:

• If the docs/original PR semantic is canonical, this is a Doris behavior bug. The fix should update both BE runtime splitting and FE constant folding, then update regression baselines for master and the maintained 3.x/4.x branches. Please include cases for split_by_string('', ','), split_by_string('', ''), and non-constant column delimiters so folded and non-folded execution stay consistent.
• If the current [] behavior is canonical, the 4.x docs and examples should be corrected so they do not promise [""].

Related public issue: #64720 reports the same empty-input expectation at the explode_split("", ",") layer. That issue may need the same semantic decision, because a split_by_string behavior change could affect table-function behavior.

Missing info: no profile or server log is needed for this report. The useful additions would be the exact 3.x and 4.x build versions tested, and whether the expected [""] behavior is based on Doris 4.x docs, compatibility with another engine, or both.