Implicitly set prefix lengths for Doltgres #2687
Closed
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 change allows Doltgres customers to use
TEXTcolumns in secondary indexes andUNIQUEconstraints.MySQL requires that users specify a prefix length when using a
TEXTorBLOBcolumn in a secondary index (also in the primary key, but Dolt/GMS doesn't support that currently). PostgreSQL does not have a concept of prefix lengths. Including the fullTEXTcontent in an index introduces problems with our 65kb row size limit and allowing a secondary index to include an address and de-ref it inTupleComparatoris a larger/messier change. Implicitly setting a prefix length is a pragmatic way to get the right behavior, without doing the large refactoring to allow secondary indexes to support address-encoded values correctly. That work seems to be required before we can supportTEXTcolumns being used in primary keys, too.I played with a few ways to structure this behavior difference. My first choice way to refactor out a separate analyzer rule that Doltgres could insert, but that turned into a lot of copy and paste that didn't seem easier to maintain, so I tried adding a
EngineTypeproperty toAnalyzerso that code can be aware of what type of engine it is emulating and switch on that for different behaviors. I may still take another pass at a separate analyzer rule, just to try that approach again – putting that analyzer rule in GMS, instead of in Doltgres, could prevent some of the copy/paste, without having to export additional, small helper functions.