Fix hex string to varchar conversion #2939
Open
Conversation
This file contains 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
Signed-off-by: Rishabh Tanwar <ritanwar@amazon.com>
Signed-off-by: Rishabh Tanwar <ritanwar@amazon.com>
Signed-off-by: Rishabh Tanwar <ritanwar@amazon.com>
Signed-off-by: Rishabh Tanwar <ritanwar@amazon.com>
rishabhtanwar29
requested review from
rohit01010,
Deepesh125 and
tanscorpio7
and removed request for
Deepesh125
Deepesh125
reviewed
Sep 21, 2024
| if (*utf == '\0') | ||
| break; | ||
| { |
There was a problem hiding this comment.
These routines are being used to send the data of string data type with different collation to end client, how are we making sure that this change will not regress anything existing?
| @@ -271,6 +277,12 @@ TsqlUtfToLocal(const unsigned char *utf, int len, | |||
| } | |||
| iutf = (b1 << 24 | b2 << 16 | b3 << 8 | b4); | |||
|
|
|||
| if (!pg_utf8_islegal(cur, l)) | |||
There was a problem hiding this comment.
Just curious, how are we making sure that our test cases covers case which hits "break" previously?
| * instead of plain strlen since strlen calculates string upto first null character (\0) | ||
| * even though the input string might contain more characters. | ||
| */ | ||
| if (pltsql_plugin_handler_ptr->is_tsql_varchar_or_char_datatype(col->pgTypeOid)) |
There was a problem hiding this comment.
why do we need this check?
| * ex: CAST(CAST('a' AS BINARY(10)) AS VARCHAR) should work | ||
| * and not fail because of null byte | ||
| */ | ||
| while(len>0 && data[len-1] == '\0') |
There was a problem hiding this comment.
it makes sense if we dont remove trailing zeroes for binary, but we should remove them for varbinary, right? what is expected tsql behaviour?
| @@ -437,7 +437,6 @@ BABEL-4672 | |||
| permission_restrictions_from_pg | |||
| BABEL-730-before-15_6-or-16_1 | |||
| GRANT_SCHEMA-before-15_7-16_3 | |||
| babel-4475 | |||
| @@ -198,6 +198,9 @@ DECLARE @inputString BINARY(10) = 0x61626364656667, @pattern BINARY(10) = 0x6364 | |||
| SELECT replace(@inputString, @pattern, @replacement) | |||
| GO | |||
|
|
|||
| UPDATE babel_4836_replace_t4 SET a = 0x6162636465, b = 0x6263, c = 0x747576; | |||
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
Varbinary to varchar conversion results in error if the binary input contains non-printable
UTF8 characters or NULL character. PG natively supports such behavior of throwing error
for untranslatable characters but this is not true for T-SQL. T-SQL just keeps all unrecognized
characters bytes into the resultant varchar string instead of throwing error so that it is upon
client to handle them, most of the clients replace unrecognized characters with a
?.This commit fixes this issue by handling non-printable and NULL characters in a string instead
of throwing error. This is achieved by keeping the unrecognized bytes as it is in the output
string so that it is upon client to handle such characters. This is important to note that the PG's
internal logic to handle NULL (0x00) character remains same so any string operations on strings
containing NULL character might generate different result compared to T-SQL standard.
Task: BABEL-4562
Signed-off-by: Rishabh Tanwar ritanwar@amazon.com
Test Scenarios Covered
Use case based -
Boundary conditions -
Arbitrary inputs -
Negative test cases -
Minor version upgrade tests -
Major version upgrade tests -
Performance tests -
Tooling impact -
Client tests -
Check List
By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.