Fix isc_array_lookup_desc/bounds length of text arrays on attachments with another character set - #9182
Open
madorin wants to merge 1 commit into
Open
Fix isc_array_lookup_desc/bounds length of text arrays on attachments with another character set#9182madorin wants to merge 1 commit into
madorin wants to merge 1 commit into
Conversation
… with another character set Text elements of the array API are exchanged in the attachment character set (blr_text/blr_varying without a character set), but the length was the column length in bytes of the column character set. On a UTF8 attachment a VARCHAR(15) column in NONE or a single-byte character set got 15 bytes, i.e. 3 characters, and isc_array_get_slice/put_slice failed with string right truncation. Use the declared number of characters in the attachment character set when it's longer, as DSQL does for messages.
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
1 participant
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.
Fixes #4109.
isc_array_lookup_desc/isc_array_lookup_boundsdescribe text elements asblr_text/blr_varyingwithout a character set, soisc_array_get_slice/isc_array_put_sliceexchangethem in the attachment character set. But
array_desc_lengthwasRDB$FIELD_LENGTH, the lengthin bytes in the column character set. On a UTF8 attachment a
VARCHAR(15)column in NONE or asingle-byte character set got 15 bytes, i.e. 3 characters, and reading or writing longer values
failed with "string right truncation".
The length is now the declared number of characters (
RDB$CHARACTER_LENGTH) times the bytes percharacter of the attachment character set (
frb_info_att_charset), as DSQL does for messages,when it's longer than
RDB$FIELD_LENGTH(limited toMAX_VARY_COLUMN_SIZE). If the attachmentcharacter set or the character length is not known, the length doesn't change. Single-byte
attachments and UTF8 columns on UTF8 attachments get the same length as before.
Tested with a debug build of the client (master and v5.0-release) against master, 5.0.4, 3.0.14
and 2.5.9 servers:
VARCHAR(15) [1:3]in NONE and WIN1251, read and written withisc_array_lookup_bounds+isc_array_get_slice/isc_array_put_sliceon UTF8 (length 60,values correct) and WIN1251 attachments (length 15, unchanged). Writing WIN1251 columns from UTF8
also needs #9181 on the server (#9180).
The same change applies to v5.0-release (there is only the query without schemas); I can open a
separate PR for the backport if needed.