fix: Move global cast to string length limit of 3000 to Db2 specific code path#1658
Open
fix: Move global cast to string length limit of 3000 to Db2 specific code path#1658
Conversation
Collaborator
Author
|
/gcbrun |
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
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.
Description of changes
This PR changes how we currently define the target data type for a CAST to string in Db2.
Db2 has a conservative approach to estimating string lengths, assuming the worst case/longest possible length. At some point during initial Db2 implementation a change was implemented to apply a length of 3000 to all casts to string. While it was intended for this to be Db2 specific the change was actually global and active across other engines. I saw it active during Sybase and Oracle testing.
This PR does not change the limit of 3000 on Db2 but modifies the location of the change to be Db2 specific. This comes with a risk though... what if by fixing one problem we create a new one in another engine that we didn't know was benefiting from the same code?
I've run all tests and they pass, I think that's all I can realistically do. But we should be prepared for subsequent changes if customer notice a negative impact.
In summary, there should be no functional change from this PR, we are only removing unintentional side effects.
Issues to be closed
Closes #1634
Checklist
CONTRIBUTINGGuide.tests/local_check.shscript)