Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bump
Created with
brew bump-formula-pr
.release notes
ItemAccess::itemWidth
to 32 bitsItemAccess
is a class used to read data out of prolly tree nodes. Because theitemWidth
field was limited to 16 bits, reading any value larger than 2^16 bytes would result in silent truncation.We don't usually store values this large, although it should be safe to do so.
This issue was discovered because the new JSON chunker (introduced in Add
IndexedJsonDocument
, aJSONWrapper
implementation that stores JSON documents in a prolly tree with probabilistic hashing. dolthub/dolt#7912) always stores embedded strings as a single chunk, so a document containing a string larger than 32KB would result in a node with a single value whose length didn't fit in 16 bits.While we were investigating this issue, we created If a JSON document contains strings that can't fit in a single chunk, use the naive Blob chunker instead of the smart JSON chunker. dolthub/dolt#8723 to disable the new JSON chunker in the presence of these long strings. This PR partially reverts that one, resuming the smart chunking of JSON even in the presence of large embedded strings.
This PR allows certain Doltgres extended types to be correctly serialized as part of keys
go-mysql-server
This adds an external function provider, currently needed for Doltgres to get function creation working. This is intended to be a temporary measure until a more permanent solution is developed (which may involve modifying Dolt's
DatabaseProvider
).golang.org/x/exp
with stdlibThese experimental packages are now available in the Go standard library.
golang.org/x/exp/slices
->slices
(https://go.dev/doc/go1.21#slices)golang.org/x/exp/maps
->maps
(https://go.dev/doc/go1.21#maps)golang.org/x/exp/constraints
->cmp
(https://go.dev/doc/go1.21#cmp)golang.org/x/exp/rand
->math/rand/v2
(https://go.dev/doc/go1.22#math_rand_v2)Comparison between
systemSetTypes
and other types is still not correct.It appears that MySQL actually treats
@@sql_mode
as just a string.This PR only fixes the panic
str_to_date
This PR fixes an issue with the
str_to_date
function where we wouldn't match string literals in the date with literals in the format, because we were improperly converting them to lowercase.Additionally, this PR has it so the
str_to_date
function returns atime.Time
instead of a string. This gets us closer to MySQL behavior over the server.fixes: Issue with "T" when using str_to_date dolthub/dolt#8807
This PR refactors a ton of the stored procedure behavior to more closely match MySQL.
Changes:
plan.Call
nodesPartially addresses: Match MySQL's handling of nested subroutine definitions. dolthub/dolt#8053
Closed Issues