expression: support newer UUID types

[dveeden]

What problem does this PR solve?

Issue Number: close #61982

Problem Summary:

What changed and how does it work?

This adds:

• UUID Generation functions for UUID v3,v4,v5,v6 and v7
• Function to extract the UUID version
• Function to extract the UUID timestamp

What this does not (yet) do is:

• function pushdown support
• A vector function for them

In other databases:

• MySQL (unofficial): https://github.com/lefred/mysql-component-uuid_v7
• Percona Server: https://www.percona.com/blog/all-uuid-functions-in-percona-server-for-mysql-rfc-9562-implemented/
• DuckDB: https://duckdb.org/docs/stable/sql/functions/utility#uuidv7
• MariaDB: https://mariadb.com/docs/server/reference/sql-functions/secondary-functions/miscellaneous-functions/uuid_v7
• PostgreSQL: https://www.postgresql.org/docs/18/functions-uuid.html

Also interesting / related:

• https://blogs.oracle.com/mysql/javascript-support-in-mysql-the-uuid-example
• https://planetscale.com/blog/the-problem-with-using-a-uuid-primary-key-in-mysql
• https://docs.pingcap.com/tidb/stable/uuid/
• https://www.pingcap.com/article/the-benefits-of-using-uuids-for-unique-identification/
• https://www.pingcap.com/article/mastering-uuid-storage-in-mysql/
• https://www.pingcap.com/article/choosing-right-uuid-type-for-database-keys/

Note that there doesn't seem to be a good standard for the function names.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

More functions were added for working with UUIDs

TODO

• Make sure timestamp extraction works with all applicable UUID versions
• Make sure timestamp extraction gives an error for UUIDs that do not store a timestamp
• Add more tests
• Check if UUID_TO_BIN() and BIN_TO_UUID() actually make sense for UUID version 3-7. I assume that MySQL accepts any UUID (including those generated outside of MySQL).
• Allow/Disallow the new functions in generated columns and as expression default

[ti-chi-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[tiprow]

Hi @dveeden. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[dveeden]

/ok-to-test

[codecov]

Codecov Report

❌ Patch coverage is 55.79710% with 61 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.6478%. Comparing base (3455e86) to head (ff7e90c).
⚠️ Report is 6 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #65007        +/-   ##
================================================
- Coverage   70.8020%   68.6478%   -2.1543%     
================================================
  Files          1901       1879        -22     
  Lines        518502     510526      -7976     
================================================
- Hits         367110     350465     -16645     
- Misses       126860     137703     +10843     
+ Partials      24532      22358      -2174     

Flag	Coverage Δ
integration	41.6059% <55.7971%> (-6.5609%)	⬇️
unit	65.9143% <0.0000%> (+0.3325%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	52.8700% <ø> (ø)
parser	∅ <ø> (∅)
br	38.4952% <ø> (-19.7346%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dveeden]

/retest

[purelind]

/retest

[dveeden]

/retest

[dveeden]

Yes, I think v7 is probably most wanted. But with TiDB UUIDv4 might also makes sense (like AUTO_INCREMENT and AUTO_RANDOM)

V4 is fine by me too. So maybe we can limit our implementation to only v4 and v7, and preserve the flexibility to do other versions otherwise in the future? (Less code, less liability).

Yes, I've removed v3, v5 and v6 in 0ff52f2

Reminder: we need to also update the doc of supported functions.

https://docs.pingcap.com/tidb/stable/miscellaneous-functions/#supported-functions

Yes, that's on my todo list. We also need to update https://docs.pingcap.com/tidb/stable/uuid/

[dveeden]

/retest

[dveeden]

/retest

[zanmato1984]

Why isn't there a line for uuid_timestamp?

[dveeden]

There should have been. I've added one and checked for more missing lines and I found a few.

diff <(grep -E '^type.*FunctionClass' pkg/expression/builtin_miscellaneous.go  | sort | cut -d\  -f2) <(grep -E '_ functionClass = .*FunctionClass' pkg/expression/builtin_miscellaneous.go | sort | cut -d\& -f2 | cut -d{ -f1)
diff <(grep -E '^type.*builtin' pkg/expression/builtin_miscellaneous.go  | sort | cut -d\  -f2) <(grep -E '_ builtinFunc = ' pkg/expression/builtin_miscellaneous.go | sort | cut -d\& -f2 | cut -d{ -f1)

The ones that were missing:

• tidbRowChecksumFunctionClass
• builtinFreeLockSig
• builtinNameConstVectorFloat32Sig
• builtinUsedLockSig
• builtinUUIDTimestampSig
• builtinUUIDv4Sig
• builtinUUIDv7Sig
• builtinUUIDVersionSig
• builtinVectorFloat32AnyValueSig

I also sorted them.

The result: 35202db

Are these lines (still) needed? What happens if they are missing?

[dveeden]

Looks like these lines might be there to ensure these types implement functionClass etc.

However this seems to already be enforced by the reference in pkg/expression/builtin.go.

[dveeden]

We could:

• Remove these 919 lines: dveeden@af0efdb
• Add GitHub action that runs checks

[zanmato1984]

I think we should probably keep them and add extra github action in followup PRs. Thanks for the update!

[dveeden]

/retest

[D3Hunter]

/approve

for the parser part

[D3Hunter]

/hold

just to avoid accidentally merged, as I am not sure whether @zanmato1984 has finished review, you can unhold youself after fixing comments from him @dveeden

[zanmato1984]

LGTM.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: D3Hunter, GMHDBJD, windtalker, zanmato1984

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [D3Hunter,GMHDBJD,windtalker,zanmato1984]
• pkg/expression/OWNERS [windtalker,zanmato1984]
• pkg/parser/OWNERS [D3Hunter]
• pkg/table/OWNERS [GMHDBJD]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[D3Hunter]

/unhold

[dveeden]

/retest

[dveeden]

/retest

[dveeden]

Reminder: we need to also update the doc of supported functions.
https://docs.pingcap.com/tidb/stable/miscellaneous-functions/#supported-functions

Yes, that's on my todo list. We also need to update https://docs.pingcap.com/tidb/stable/uuid/

pingcap/docs#22234