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
Contribution: refactor: use the built-in max/min to simplify the code dolthub/dolt#9044
NULL Adaptive values weren't being properly handled in all codepaths. Some operations during tuple building (such as trying to move them out of band) caused a panic. This fixes that and adds tests.
During the merge operation, Dolt creates a
CREATE TABLE
statement for the table being merged, parses it, and uses that information during the merge. This PR allows this process to work with a non-MySQL dialect.Fixes: Potential concurrency Issue with
call dolt_commit('--amend')
dolthub/dolt#9072Thanks to @jbampton
Use the built-in max/min from the standard library in Go 1.21 to simplify the code. https://pkg.go.dev/builtin@go1.21.0#max
Adaptive Inline encoding refers to values that can be stored either inline in a table, or out-of-band in external storage. Postgres calls them TOAST (The Oversized-Attribute Storage Technique) types.
This PR adds two new encoding types: one for toasted TEXT columns and one for toasted BLOB columns.
The important parts of this PR are:
StringToastEnc
andBytesToastEnc
ToastValue
type: this type has methods for creating and inspecting TOAST values.prolly.PutField
andprolly.GetField
to handle writing reading and writing these encodings to tuplesTupleBuilder
, which choose an inline or outlined representation for each value with a TOAST encoding. It prefers to store these values inline, but selectively outlines columns in a deterministic way if the length of the tuple would otherwise exceed a threshold. (Currently 2KB, not currently configurable.)It is not currently possible to use these encodings in Dolt proper. For testing purposes, a variable
schema.UseToastTypes
has been added. Setting this variable to true will cause Dolt to use these toast encodings for TEXT and BLOB columns instead of the normal address encodings.go-mysql-server
Most uses of
convertValue
checked if the input was nil, butBinary.Eval
didn't.NULL should always be converted to NULL, so we can just put the check there.
Dolt uses functions in the sql package to create and then parse CREATE TABLE statements as part of the merge process. Therefore, we need the ability to create these statements for other dialects, just as we do for MySQL.
This PR also exposes a Noop auth method for the same use case.
fixes Unexpected type conversion in IFNULL dolthub/dolt#9076
AND
optimizationThis PR fixes
AND
optimizations whereTRUE & x
->x
.Probably should've seen this coming given our bug fix with
OR
here,fixes: Incorrect optimization of AND operation in expression in WHERE clause dolthub/dolt#9074
fixes: Incorrect optimization of OR operation in expression in WHERE clause dolthub/dolt#9052
fixes: Trigger LEFT_JOIN indexing error dolthub/dolt#9039
Inserts nested inside triggers is a special case that we have minimal testing for. Some of the things that were broken before:
new
columns were not accessible / the index offsets estimated based on prepending trigger rows were invalidThis PR adds support for
Wrapper
values, a new type of value that the storage layer can provide to the engine. This is a generalization of the existingJsonWrapper
interface, but is not limited to JSON values.Wrapper types are useful because they can represent a value in storage without needing to fully deserialize that value for the engine. The primary use case is for "out-of-band" storage values, such as large
BLOB
orTEXT
values that aren't stored directly in tables.The Wrapper interface has the following methods:
Unwrap/UnwrapAny
- These methods both deserialize the wrapped value and return it.UnwrapAny
returns aninterface{}
, whileUnwrap
has a parameterized return type. The implementation is encouraged to cache this value.IsExactLength
- Returns true if the size of the value can be known without deserializing it.MaxByteLength
- The length of the value in bytes. IfIsExactLength
is true, this is the exact length of the value. Otherwise, it's an upper bound on the length of the value, determined by the schema of the table the value was read from.Compare
- Some Wrapper implementations may be able to compare wrapped values without needing to deserialize them. This method returns a boolean indicating whether or not this "short-circuit" comparison is possible, and an int indicating the result of the comparison.Closed Issues
call dolt_commit('--amend')