MDEV-38180: Add xxh32() and xxh3() SQL functions

[monthdev]

Address MDEV-38180.

There is already an open PR for this here #4500. I am just assuming it was dropped and reiterating with a narrower scope.

[CLAassistant]

All committers have signed the CLA.

[gkodinov]

This is a preliminary review. Thank you for your contribution.

I think you need to figure out what is the fate of the other PR. As yours seems to mostly be a fork of it (I didn't compare, but it looks very similar). I will add Daniel as a reviewer to this one so he can work on that.

Should we decide to go ahead, please make sure your commit message must be present and must follow CODING_STANDARDS.md

[monthdev]

@gkodinov I appreciate the review! In my latest commit, I

• (re)implemented xxh32(), xxh3(), and xxh3_128()
• changed SQL API to return hex string
• normalized input to stable charset before hashing
• added MTR coverage for xxh3_128() and charset consistency
• cleaned up coding style.

Please let me know of any other problems or nits!

[monthdev]

Hi, again! I looked at the failing checks, and they look unrelated to my PR to the extent that the tests do not fail on my new test file func_xxh.test/result.

[mariadb-YuchenPei]

Please use the my_hasher_st interface which is used by partitioning. It is collation-aware and the sql functions should be consistent with which partitions the string goes to.

Please add tests regarding collation equality too. A simple one could be something like checking that xxh3(' ') = xxh3(' '), given that the two strings are equal (and go to the same partition with PARTITION BY [LINEAR] KEY):

MariaDB [test]> select '' = '   ';
+------------+
| '' = '   ' |
+------------+
|          1 |
+------------+
1 row in set (0.001 sec)

P.S. It's not clear to me the context of choosing between proceeding with this PR vs #4500 given the latter is still open though appearing dormant. The review comment is independent of that.

[monthdev]

@mariadb-YuchenPei Thanks for the input! It was my mistake opening this PR. I explained that on Zulip #general > MDEV-38180 GSoC 2026 @ 💬#general > MDEV-38180 GSoC 2026 @ 💬. But then I got a code review from another maintainer, so I got confused. Please disregard my PR in favor of #4500 which was opened first! I am not trying to take someone else's PR.

[mariadb-YuchenPei]

@monthdev, I spoke to @grooverdan. We were going to wait for the #4500 contributor to update their work based on some current input. They haven't done so and the patch in its current form cannot be merged. We appreciate your courtesy in giving the opportunity for the #4500 author to complete their work. I think a reasonable amount of time has passed, and if you are willing to address and complete this PR, then ultimately the users of MariaDB will benefit from your labour.

[monthdev]

@mariadb-YuchenPei Will do! I opened another PR in the meantime #4767 (again assuming #4500), so I'll complete both as soon as I can.

[monthdev]

@mariadb-YuchenPei Made changes addressing #4741 (review)

[monthdev]

Or maybe I could open a separate reformat PR for this registry array?

[monthdev]

@mariadb-YuchenPei I scrapped xxh3_128() because it wasn't a part of the hasher interface. Maybe that could be a later feature?

[grooverdan]

Or maybe I could open a separate reformat PR for this registry array?

reformatting makes merging hard, manual and error prone. While format's have diverged, its best to constrain any reformatting to the very narrow scope of what is actually being changed.

[mariadb-YuchenPei]

A quick comment. Still looking.

[mariadb-YuchenPei]

Are strings all converted to my_charset_utf8mb4_general_ci before being hashed? They shouldn't be.

If one applies this diff

modified   mysql-test/main/partition_key_algorithm.test
@@ -136,6 +136,7 @@ DROP TABLE t1;
 CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET koi8u COLLATE koi8u_general_ci);
 INSERT INTO t1 VALUES (0x20),(0x60),(0x6060),(0x606060);
 SELECT HEX(a) FROM t1 WHERE a=0x60;
+select xxh3(a) from t1;
 eval
 ALTER TABLE t1  PARTITION BY KEY $algo (a) PARTITIONS 3;
 SELECT HEX(a) FROM t1 WHERE a=0x60;

and run the test, we have

--- /home/ycp/source/mariadb-server/main/src/mysql-test/main/partition_key_algorithm.result	2026-03-13 16:20:20.733682895 +1100
+++ /home/ycp/source/mariadb-server/main/src/mysql-test/main/partition_key_algorithm.reject	2026-03-13 16:45:41.878718485 +1100
@@ -193,6 +193,12 @@
 60
 6060
 606060
+select xxh3(a) from t1;
+xxh3(a)
+0000000000000000
+dfce7d3ab64b81ae
+684d238e39c1c15c
+28e8eabcf16c906a
 ALTER TABLE t1  PARTITION BY KEY  (a) PARTITIONS 3;
 SELECT HEX(a) FROM t1 WHERE a=0x60;
 HEX(a)

But all four values should be the same because they are equal under "CHARACTER SET koi8u COLLATE koi8u_general_ci" (see the previous statement in the test).

[monthdev]

@mariadb-YuchenPei Let me know if my change is how you wanted it!