Skip to content

Conversation

@makiuchi-d
Copy link
Contributor

@makiuchi-d makiuchi-d commented Oct 4, 2025

This PR provides an optional pure Go regex engine that allows building go-mysql-server without CGO.
The default build process (using ICU via CGO) remains unchanged.

Implementation

  • With CGO (default): Uses the existing go-icu-regex library. (internal/regex/regex_cgo.go)
  • Without CGO (CGO_ENABLED=0 or -tags=gms_pure_go): Uses a new implementation based on Go's standard regexp package. (internal/regex/regex_pure.go)

Build selection is handled via Go build tags.

Compatibility Notes

The pure Go engine trades compatibility for portability, as it is based on standard regexp package.

Notable limitations compared to ICU include:

  • Lack of back-references
  • No before/after text matching
  • Differences in handling CR ('\r')
  • Other minor differences

This change allows running the server in pure Go for users who can accept the trade-offs, providing greater build flexibility.

@makiuchi-d
Copy link
Contributor Author

makiuchi-d commented Oct 6, 2025

Add gms_pure_go build tag for pure-Go build with CGO enabled.

@timsehn
Copy link
Contributor

timsehn commented Oct 6, 2025

@reltuk should review this on our side.

@timsehn timsehn requested a review from reltuk October 6, 2025 16:57
Copy link
Contributor

@reltuk reltuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great. Thank you for the contribution! I'm going to go ahead and land it.

@reltuk reltuk merged commit 56af719 into dolthub:main Oct 7, 2025
8 checks passed
@reltuk
Copy link
Contributor

reltuk commented Oct 8, 2025

@makiuchi-d I wanted to let you know that in (#3223) we made the build tag gms_pure_go necessary in order to build against the regex.Regex implementation. We were concerned about users accidentally picking up the non-compliant implementation without realizing it when they were compiling without Cgo.

I hope this is not too much trouble for you and we are open to feedback about it and ways to improve the process in general.

Thanks again for your contribution!

@makiuchi-d
Copy link
Contributor Author

@reltuk
That change makes sense to me, and it’s no problem at all.
Thanks for the heads-up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

4 participants