key type conversion during foreign key checks#10935
Merged
Merged
Conversation
Contributor
|
@zachmu DOLT
|
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This PR adds key type conversion for native encodings (encodings that don't have a TupleTypeHandler) for foreign key enforcement during merge. Postgres, but not MySQL, allows different but compatible types for the columns in foreign key constraints, e.g TEXT and VARCHAR. This means that Doltgres, but not Dolt, needs to sometimes convert the bytes of a tuple value from one encoding to another before an index lookup to determine if a constraint violation exists. Previously all such logic happened with TupleTypeHandler (DoltgresType was the main implementor). But with dolthub/doltgresql#2559, Doltgres is now using Dolt's native encodings where possible, e.g. StringEnc, StringAdaptiveEnc. This means this same logic must now work for these native encodings.
Dolt continues to prevent foreign key constraints from being created between different types, following the MySQL behavior, but with this change we could choose to relax this limitation in the future.