add UUID functions - #24807
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
XuPeng-SH
left a comment
XuPeng-SH
left a comment
There was a problem hiding this comment.
I reviewed this from correctness / behavior-compatibility / coverage angles, and there is one blocking issue:
uuid_short()is currently implemented asxxhash.Sum64(uuid.NewV7()). That is not MySQL-compatible. MySQL documentsUUID_SHORT()as a 64-bit value built from(server_id << 56) + (startup_time << 24) + incrementing_counter, specifically to preserve uniqueness under documented conditions and to produce increasing values. Hashing a 128-bit UUID down to 64 bits removes both of those properties: collisions become possible by construction, and call order is no longer monotonic.
The official MySQL docs for UUID_SHORT() are explicit about this contract, and the current implementation does not match it. I think this needs either:
- a real
UUID_SHORT()implementation with server/startup/counter semantics, or - a different function name if the intention is to expose a hashed UUID-derived helper rather than MySQL-compatible behavior.
The current tests also only check uuid_short() is not null / > 0, so they would not catch the semantic mismatch above.
删除了uuid_short. 一是不在issue需求. 二是 mysql的实现方案 在 mo 多cn中不好做. |
XuPeng-SH
left a comment
XuPeng-SH
left a comment
There was a problem hiding this comment.
I found one substantive MySQL-compatibility issue in the new swap_flag support for UUID_TO_BIN() / BIN_TO_UUID().
This PR explicitly broadens the accepted swap_flag types to include strings (uuidSwapFlagTypeSupported() accepts MySQL string types), but the string branch in makeBoolParamGetter() uses strconv.ParseFloat on the entire string. That is stricter than MySQL’s coercion rules: values like 1abc / 2xyz are truthy in MySQL because boolean evaluation consumes the leading numeric prefix, but this implementation treats any parse failure as false and returns the unswapped result.\n\nSo right now the function signature says string swap flags are supported, but some supported string inputs do not behave like MySQL. I also do not see coverage for this path in the added SQL or unit tests — current tests cover clean numeric values like 0.4, -0.4, 0.0, but not prefix-numeric strings. I think this should either use MySQL-compatible string-to-number coercion for the boolean evaluation, or reject non-numeric strings explicitly instead of silently treating them as 0.
mo不支持前缀数字字符串 转成 数字. 现在改为报错. |
XuPeng-SH
left a comment
XuPeng-SH
left a comment
There was a problem hiding this comment.
I re-checked the latest update and this looks good to me now.
The key point I cared about before was the swap_flag string path. This version makes the behavior explicit and internally consistent: if a string swap flag cannot be parsed as a numeric value, it now errors instead of being silently treated as false. That is stricter than MySQLs loose numeric-prefix coercion, but as an intentional MO behavior it is coherent, well-covered by the new unit and SQL tests, and much better than the previous silent fallback.
Merge Queue Status
This pull request spent 42 seconds in the queue, including 7 seconds running CI. Required conditions to merge
|
5 participants
What type of PR is this?
Which issue(s) this PR fixes:
issue #24486
What this PR does / why we need it:
增加uuid函数: is_uuid, uuid_short, uuid_to_bin, bin_to_uuid