[
https://issues.apache.org/jira/browse/DERBY-4040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4040:
-----------------------------------
Attachment: derby-4040-1a-SQLChar_length_and_test.stat
derby-4040-1a-SQLChar_length_and_test.diff
'derby-4040-1a-SQLChar_length_and_test.diff' fixes the bug by always decoding
the stream is the data value is stored as a stream, and it also adds a few more
tests (adjusted existing test).
The bug was that the byte length was used as a character length. Since these
two lengths are the same for ASCII data values, it wasn't detected earlier. The
limited range of the length information in the header helped conceal the bug
too.
Ran regression tests without failures. I'll look at backporting the fix when it
has made it into trunk.
Patch ready for review.
> SQLChar.getLength returns wrong length for some data values
> -----------------------------------------------------------
>
> Key: DERBY-4040
> URL: https://issues.apache.org/jira/browse/DERBY-4040
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.3.1, 10.4.2.0, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: derby-4040-1a-SQLChar_length_and_test.diff,
> derby-4040-1a-SQLChar_length_and_test.stat
>
>
> SQLChar.getLength() returns the wrong length of the data value in some cases.
> For the bug to be triggered, the value must contain characters that are
> represented by two or three bytes, and Derby must store the value as a stream.
> In my ad-hoc testing, I found that a value of length 10886 with CJK
> characters doesn't trigger the bug, but 10887 does trigger the bug. Further,
> for a range of lengths the bug can also been observed for CLOB columns (when
> doing 'select length(clobcolumn)').
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
